practices - params comments c#
C#Namespaces and Assemblies Mejores prácticas (3)
C #: ¿hay alguna guía, mejores prácticas cuando se trata de dividir una solución en espacios de nombres y ensamblajes? ¿Los espacios de nombres normalmente deben estar anidados, con las clases más bajas y fundamentales en el espacio de nombres de nivel superior? ¿Debería haber generalmente un nombre-espacio para una asamblea? ¿Son sus dificultades para tener múltiples conjuntos en un nombre-espacio o múltiples espacios de nombre en un conjunto. ¿Hay penalizaciones de tiempo de compilación / tiempo de ejecución para ensamblajes múltiples o ensamblajes muy grandes?
C #: ¿hay alguna guía, mejores prácticas cuando se trata de dividir una solución en espacios de nombres y ensamblajes?
Para obtener instrucciones sobre espacios de nombres, lea las pautas de diseño del marco.
Para ensamblajes: un ensamblaje es, por definición, la unidad más pequeña e independiente de la funcionalidad de autodescripción que se puede enviar en .NET. ¿Hay partes de su software que desea enviar o versiones de forma independiente? Entonces deberían estar en diferentes asambleas.
¿Los espacios de nombres normalmente deben estar anidados, con las clases más bajas y fundamentales en el espacio de nombres de nivel superior?
No necesariamente, no.
Los espacios de nombres deben diseñarse de modo que sea fácil para los usuarios descubrir y comprender los tipos contenidos en esos espacios de nombres. Tal vez deberías preguntarles a tus usuarios qué piensan.
¿Debería haber generalmente un nombre-espacio para una asamblea?
No necesariamente, no.
¿Son sus dificultades para tener múltiples conjuntos en un nombre-espacio o múltiples espacios de nombre en un conjunto.
No particularmente, no.
¿Hay penalizaciones de tiempo de compilación / tiempo de ejecución para ensamblajes múltiples o ensamblajes muy grandes?
No que yo supiese.
Los espacios de nombres son solo una forma elegante de dividir los nombres completos de las clases para la conveniencia del usuario. Por lo tanto, no hay penalizaciones o ganancias de compilación / tiempo de ejecución para usar espacios de nombres.
La división de objetos en ensamblajes tendrá un impacto en el tiempo de ejecución y en el tiempo de compilación, también es poco probable que sea alto si no se utiliza una gran cantidad de ensamblajes. Tenga en cuenta que no es posible predecir qué obtendrá ganancias o lentitud sin medidas reales para su caso particular.
Debe dividir su proyecto en ensambles en función de sus necesidades lógicas (es decir, por subsistemas) / técnicas (es decir, debido a las versiones de los componentes) y de verificar si el rendimiento es aceptable. Si no, tendrá que averiguar dónde están los problemas antes de culparlo por el número de ensamblajes.
Para dar seguimiento a lo que dijo Eric Lippert:
Nombres de Asamblea
Es tradicional que casi todos los códigos en un espacio de nombres vivan en un solo espacio de nombres y espacios de subnombres, con el ensamblado nombrado después del espacio de nombres.
Por ejemplo, si se me proporcionó un ensamblado con el nombre de archivo Contoso.PartnerPortal.Services.dll , el nombre corto del ensamblado sería Tradicionalmente Contoso.PartnerPortal.Services , y esperaría que la mayor parte del código Contoso.PartnerPortal.Services en el Contoso.PartnerPortal.Services nombres de servicios (y espacios de nombres secundarios).
Sin embargo, no todas las clases en el espacio de nombres Contoso.PartnerPortal.Services necesariamente vivirán en el ensamblado Contoso.PartnerPortal.Services.dll. Si existe un ensamblado Contoso.PartnerPortal.dll , es posible que también tenga algunas clases en el espacio de nombres Contoso.PartnerPortal.Services .
Un uso común de esto es con las interfaces. Si las interfaces viven en Contoso.PartnerPortal.dll , el código en ese ensamblado puede usar la interfaz sin hacer referencia a Contoso.PartnerPortal.Services.dll . Esto es importante, ya que Contoso.PartnerPortal.Services.dll (que implementará las interfaces) probablemente necesite hacer referencia a Contoso.PartnerPortal.dll y es mejor evitar las referencias de ensamblado circular.
Número / Tamaño de ensambles
Los ensambles que son excesivamente grandes pueden hacer que la compilación tarde más de lo necesario. Esto se debe a que los compiladores no han tenido soporte para la compilación incremental en bastante tiempo. Por lo tanto, un módulo completo debe compilarse como una unidad. Dado que los conjuntos de varios módulos no se utilizan con frecuencia, esto básicamente implica que debe compilar un conjunto completo a la vez.
Si divide un ensamblaje grande en varios más pequeños, solo se volverá a compilar el ensamblaje modificado y los que hacen referencia. Eso ahorra algo de tiempo.
En el otro extremo, tener más de 600 ensamblajes en una aplicación (yo trabajo en semejante monstruo en mi trabajo diario) tiene su propio conjunto de problemas. Por ejemplo, la característica de copia oculta de ASP.net ha tenido problemas de rendimiento al trabajar con muchos ensamblados (tenga en cuenta que esto se suma a la gran cantidad de ensamblados creados cuando ASP.net compila los archivos aspx y ascx).