¿Qué es mejor, muchos ensambles pequeños o un ensamblaje grande?

Todo está en el título :)¿Qué es mejor, muchos ensambles pequeños o un ensamblaje grande?

Actualmente, tenemos una solución VS2005 con más de 20 proyectos. Como

MySolution 
MySolution.Modules.Foo 
MySolution.Modules.Bar 
[insert many here] 
MySolution.Modules.Baz

¿Puede haber un daño al "fusionar" MySolution.Modules. * En un proyecto? Todos los espacios de nombres se conservarán, por lo que no hay problema aquí.

¿Pero hay algo en lo que no haya pensado?

Nota: Actualmente, no puede haber referencias circulares: si MySolution.Modules.Foo hace referencia a MySolution.Modules.Bar, MySolution.Modules.Bar no puede hacer referencia a MySolution.Modules.Foo. Entonces tendremos que tener cuidado de no crear algunos.

Fuente

2009-02-20 mathieu

He estado en un par de empresas en las que tener mucho demasiados proyectos han sido un dolor de varias maneras. Todavía no he estado en ninguna parte que tuviera demasiados proyectos de , aunque eso es ciertamente posible.

Considere un proyecto como una unidad de reutilización, entre otras cosas. ¿Algún producto va a necesitar Foo pero no Bar, o viceversa? Si no, unirlos.

Me gusta mantener separadas las diferentes capas (presentación, lógica comercial, acceso a datos), y es bueno tener una biblioteca común de utilidades independiente del producto, pero eso es todo en muchos casos.

Ah, y mantener pruebas en un proyecto diferente a su código de producción, por supuesto :)

Fuente

2009-02-20 08:56:38

Por otro lado, el diseño impulsado por el dominio se inspira en la división vertical de su código. – Slampen

@Slampen: No tengo suficiente experiencia de DDD para decir. –

Creo que el dolor que sufres con muchos proyectos pequeños está oculto si todos están en un gran bloque. – Slampen

Ventajas de un ensamblaje:

potencialmente Potencia
potencialmente más fácil el despliegue

Ventajas de muchas asambleas:

Todo lo demás. Asumiendo que estos son buenos módulos cohesivos, que ayuda con la separación de las capas, mantiene dependencias en jaque por lo que obligó a pensar en la nivelación/estratificación de su arquitectura, etc.

Fuente

2009-02-20 08:55:43 Brian

¿No tener muchos ensambles pequeños ralentiza el rendimiento del estudio visual? ¿Y cada conjunto individual no tiene gastos generales al crear los metadatos y los símbolos de depuración? –

@MeyerDenney ver http://stackoverflow.com/a/1218220/59996 – Aligma

tiempo de compilación. Si su proyecto se rompe en pedazos, solo se debe compilar la pieza que se modificó. Si todo es parte de un gran proyecto, tendrás que recompilar todo cada vez que cambies algo. Dependiendo de cuán grande sea su proyecto, esto puede ser un gran problema.

Fuente

2009-02-20 08:59:09

Nunca he visto que esto sea un gran problema para los proyectos de C#. Por el contrario, la sobrecarga de MSBuild parece más pesada que el compilador de C# a veces. (Esta es una evidencia completamente anecdótica por cierto.) –

Por un lado, Visual Studio comienza a tardar más y más en cargar su solución si tiene toneladas de proyectos, a diferencia de algunos proyectos con toneladas de código en ellos.

Esto no es necesariamente una buena razón para tener un solo proyecto, sobre todos los demás mencionados aquí, pero algo a tener en cuenta.

Fuente

2009-02-20 08:59:57

He oído esto antes, pero nunca lo experimenté. ¿Puedes definir 'toneladas'? Tengo una solución con> 50 proyectos y se carga como un rayo. –

Puede haber otros factores involucrados. Estamos usando TFS y puede pasar tiempo refrescando el estado del control de fuente, pero nuestra solución contiene 45 proyectos y puede consumir unos buenos 30 segundos para cargar al máximo. De acuerdo, no mucho, pero las pruebas muestran que esto está relacionado con la cantidad de proyectos. –

@Kent, he estado allí y sentí el dolor – johnc

Usamos ILMerge para unir todos nuestros pequeños conjuntos en un bloque más grande. Especialmente ensambles que están en diferentes proyectos pero que en última instancia son parte del mismo espacio de nombre.

Por ejemplo, tenemos muchas entidades de datos para registros y vistas distribuidas en una serie de conjuntos, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll, etc. al final usamos ILMerge para ponerlos juntos en un único MJ.DE.DLL. - hace que actualizar/sincronizar la aplicación sea más fácil ya que hay menos piezas con las que trabajar en el servidor de producción y sabemos que todas las clases relacionadas provienen de la misma compilación.

Fuente

2009-07-28 05:34:53 MikeJ

¿Qué es mejor, muchos ensambles pequeños o un ensamblaje grande?

Respuesta

Cuestiones relacionadas