Pautas de espacio de nombres y nombre de clase

Tengo problemas para nombrar mis clases y servicios correctamente cuando se utilizan utilidades y otras clases de ayuda.

¿Cómo estructuraría lo siguiente?

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc ...

Tengo múltiples servicios con las mismas necesidades que el servicio anterior. Un pensamiento es separar todo esto en un espacio de nombres adecuado, haciendo que se vea más o menos así:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

y así. Cada espacio de nombres es, por supuesto, una carpeta separada. Pero esto no se siente al 100%, ya que probablemente haya más DateValidatorsen los otros servicios, lo que puede conducir fácilmente a una referencia no deseada.

Y también Services.EventService.EventService.csincluye el nombre de la clase en el espacio de nombres, que tampoco es bueno. Podría usar Services.Event.EventService.cs, pero por supuesto ya existe una entidad con ese nombre.

Este es el modelo de dominio.

Creo que lo más importante que puedes hacer para mejorar tu espacio de nombres aquí es eliminarlo Servicede tu EventServiceespacio de nombres. También ajustaría los espacios de nombres para que sean más así:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Sin embargo, todavía creo que eso podría mejorar.

Me gustaban los espacios de nombres, pero hoy en día creo que menos es más. Anidar profundamente sus espacios de nombres puede hacer que su código sea demasiado detallado, y desglosar las cosas en gran medida reduce su capacidad de herencia. En su código, por ejemplo, una DateValidatorclase podría usarse fácilmente en otro lugar, por lo que no debería tener muchos espacios de nombres por encima, ya que los servicios que no sean EventService ahora pueden aprovechar una clase DateValidator. Lo mismo se aplica a los métodos de extensión. No hay tiempo (que pueda ver) en el que necesite ver todos sus métodos de extensión al mismo tiempo, por lo tanto, tiene más sentido agruparlo con lo que se relaciona. En este caso, EventExtensionsprobablemente se vincule a tu EventService, por lo que lógicamente deberían sentarse juntos en mi opinión.

¿Por qué no lee las Pautas generales de nomenclatura y las Pautas de nomenclatura de espacio de nombres de Microsoft para seguir un patrón universal?

Creo que la fórmula <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]simplemente funciona bien.

El diseño adecuado del espacio de nombres considerará tanto el diseño lógico como el físico.

Aunque la justificación original de los espacios de nombres era principalmente para evitar conflictos de nombres entre los nombres de objetos y métodos, se ha convertido en un elemento importante en la arquitectura y el diseño de la solución general. No solo desea que su jerarquía conceptual y su diseño lógico tengan sentido, sino que también desea que su código se empaquete ordenadamente en bibliotecas bien diseñadas y fácilmente reutilizables que se puedan agrupar fácilmente en otros proyectos y productos más adelante. Ese es quizás más el resultado deseado de un buen diseño físico.

Mire el .NET Framework y cómo se le proporcionan unidades de funcionalidad relacionada en ensamblajes de tamaño razonable. Puede colocar una referencia y una declaración de uso y, de repente, tiene una funcionalidad relevante disponible sin tener que arrastrar ningún número de fregaderos de cocina. Esto se debe a que el diseño físico de .NET Framework, incluido el espacio de nombres inteligente, ha empaquetado código relacionado lógicamente en unidades desplegables relacionadas físicamente. Al crear un mapeo excelente entre espacios de nombres y ensamblajes, los arquitectos y desarrolladores del marco .NET de Microsoft han hecho su trabajo significativamente más fácil (por supuesto, algunos pueden argumentar lo contrario, pero estoy bastante contento con lo que hicieron).

El espacio de nombres en C # es bastante arbitrario, en realidad. Puede colocar espacios de nombres en los lugares más extraños, en conjuntos muy alejados entre sí. Cualquier disciplina útil en esta área es realmente su contribución personal a un producto de software bien organizado. No me atrevería a aconsejarle exactamente qué hacer en cada caso. Lo que espero lograr, en esta respuesta, es que piense en el diseño físico y el diseño lógico cuando defina sus espacios de nombres. Cuanto más mantenga las cosas lógicamente relacionadas y agrupadas de manera desplegable (físicamente), las cosas serán más fáciles más tarde, tanto para usted como para otras personas que podrían necesitar tratar su código algún día.

Por lo tanto, piense en cómo se empaquetará su código en ensamblajes y componentes cuando resuelva sus problemas de espacio de nombres.