.net - compuestos - NET: ¿Mejores prácticas/pautas para dividir espacios de nombres entre archivos?
separar nombres y apellidos en excel formula (5)
Debería haber una correspondencia de uno a uno entre las clases y los archivos fuente.
Los espacios de nombres deben considerarse como un paquete que puede abarcar una o más clases. Siempre que sea posible, puede ser útil representarlos como carpetas / filtros en la ventana del proyecto de Visual Studio.
Si encuentra una clase importante que cree que se beneficiaría al dividirse en archivos separados, considere refactorizar y dividir la clase.
La excepción (aceptable) a esto es el código que genera la interfaz de usuario que Visual Studio coloca en un archivo separado. Recomendaría dejar esto en su propio archivo y tratarlo como un archivo transparente propiedad del editor tanto como sea posible.
¿Cuáles deberían ser las pautas generales / consejos para dividir el código de la aplicación (App_Code) en archivos separados?
Descubrí que, con el tiempo, los archivos originales no coinciden bien con la evolución de la jerarquía del espacio de nombres. ¿Cómo organizo contenedores de códigos de aplicaciones organizados intuitivamente con el tiempo?
¿A qué PROPÓSITO deberían aspirar las divisiones de archivos? ¿Portabilidad del código? ¿Separación de intereses? Contexto funcional general? Frecuencia de cambio? ¿Deberían luchar por una relación 1-1 con las clases?
¿Cuáles son las implicaciones de dividir el código en MUCHOS archivos más pequeños vs consolidado en pocos archivos?
A menudo he pensado en esto, pero nunca llegó a ninguna conclusión general que se aplique a todas las situaciones.
Hago un 99% de 1 a 1 clase para archivar. La única excepción es si tiene un gran número o pequeñas clases muy simples que implementan la misma interfaz y no deberían cambiar mucho. Es posible que desee seguir adelante y ponerlos en un solo archivo. Las excepciones personalizadas pueden ser un buen ejemplo. La mayoría de las veces (en mi experiencia), no hay otro código que crear mensajes personalizados o cosas de esa naturaleza.
Los espacios de nombres deben organizarse primero por separación de preocupaciones. Los objetos de datos deben estar en un espacio de nombres diferente de los objetos de dominio, por ejemplo. Entonces, puede tener un subdominio más pequeño para cada grupo de objetos en el nivel de "raíz agregada". Generalmente, cada uno de estos espacios de nombres más pequeños corresponde a su propio proyecto y DLL.
La mayoría de las recomendaciones que vi dicen que cada tipo público debe estar en su propio archivo y los espacios de nombres deben representar la estructura de la carpeta de la aplicación.
La respuesta a esta pregunta no es absoluta, ya que a menudo depende de la tarea que tenga a mano. Si está creando algún tipo de SDK para su reutilización, los espacios de nombres son muy importantes; sin embargo, si está creando una herramienta interna con solo unas pocas clases, los espacios de nombres son prácticamente irrelevantes.
Clases
En general, las clases deben tener su propio archivo ya que esto simplifica la forma en que las personas navegan alrededor de la solución de código, ayudando con el desarrollo y mantenimiento (es mucho más difícil fusionar los cambios cuando todos cambian los mismos archivos, por ejemplo). Puede ser aceptable dividir una clase en varios archivos en algunas situaciones, como:
Cuando hay clases anidadas, cada clase anidada podría tener su propio archivo.
Cuando hay porciones generadas automáticamente para la clase, como el código de diseñador.
Cuando hay partes fijas para la clase, como un conjunto común de propiedades ocultas o una implementación común de una interfaz.
En uno de nuestros proyectos, tenemos una implementación común de una interfaz que exponen muchas clases. Como no tenemos herencia múltiple, tomamos un enfoque de combinación por el cual autogeneramos un archivo adicional para cada clase. Esto podría hacerse manualmente, en lugar de hacerlo automáticamente (y lo fue, originalmente).
Hay otras situaciones, pero esto es algo subjetivo y depende de los requisitos de su propio proyecto.
Espacios de nombres
Los espacios de nombre generalmente deben enfocarse en agrupaciones sensatas de sus tipos. Un espacio de nombre debería permitir que un desarrollador ubique de manera intuitiva lo que está buscando. Para muchos proyectos pequeños, un solo espacio de nombres como MyAwesomeTool es suficiente, pero para un proyecto más grande con muchas clases necesitará una agrupación más lógica. Tales proyectos grandes, como los SDK o el .NET BCL se basan en los espacios de nombres para desglosar la colección de tipos, que de otro modo sería abrumadoramente grande. Cada nivel de espacio de nombres proporciona información adicional de lo que podría encontrarse allí, como System.Windows.Forms o System.Drawing o Microsoft.VisualBasic .
Al crear espacios de nombres, se debe tener en cuenta el propósito de ese espacio de nombres y el proyecto asociado. Si el proyecto es interno y pequeño, llame al espacio de nombre de su preferencia, ya que es simplemente una necesidad para agrupar sus tipos; si el proyecto es visible externamente o contiene una gran cantidad de tipos, piense detenidamente acerca de agrupaciones lógicas y significativas que permitan a los demás encontrar intuitivamente los tipos que están buscando.
Conclusión
No existen reglas duras y rápidas que funcionen en todas las situaciones. La forma en que organice su código en archivos se relaciona con sus propios procesos de desarrollo, impactando a usted y a su equipo; todas sus clases en un solo archivo serán un infierno para desarrollar, pero el producto compilado no actuará de manera diferente (siempre que el enfoque de un archivo no conduzca a errores), mientras que la disposición de sus espacios de nombres se relaciona con el desarrollo futuro y los consumidores de esos espacios de nombres, por lo que las consecuencias de equivocarse pueden ser más serias.
- Intente organizar sus clases de una manera que simplifique el desarrollo actual y el mantenimiento futuro.
- Intente organizar sus espacios de nombres de una manera que simplifique todo el desarrollo y, cuando corresponda, la experiencia de sus usuarios finales.
En cuanto a las clases, tiendo a seguir la regla de Java: "Una clase pública por archivo" Puedo incluir una clase privada con el público si esa clase pública es el único usuario. (Aunque, las enumeraciones lo están haciendo menos importante); Sin embargo, si es utilizado por muchas clases públicas en el mismo espacio de nombres, lo pondré en su propio archivo.
Tiendo a usar espacios de nombres a lo largo de las líneas de:
MyAwesomeApp.UI
MyAwesomeApp. Negocio
MyAwesomeApp.Data
para reflejar la separación de capas.