¿Son malas las aplicaciones con muchos archivos DLL?

Question

Tenemos una aplicación web de enterpise que constaba de 4 componentes compilados (DLL). Hace más de un año, comenzamos a implementar componentes más granulares en un intento de aislar la funcionalidad, reducir el acoplamiento y reducir el riesgo de recompilar y desplegar grandes cantidades de código. Si bien nadie aduce que este enfoque nos haya brindado MUCHA flexibilidad y velocidad en el mercado al agregar nuevas funcionalidades y reparar errores, las aplicaciones ahora constan de casi 40 dlls. Tenemos una convención de nomenclatura que funciona bien para identificar nuestros componentes.

Mi pregunta es: ¿Hay algún inconveniente (Rendimiento, mantenimiento, etc ...) en tener una aplicación con muchos dlls?

Editar: Estamos explorando la opción de código de refactorización en componentes más grandes que creo que podría ser una regresión de tipo ...

Answer 1

Mi pregunta es: ¿Hay alguna abajo del lado (rendimiento, mantenimiento, etc ...) para tener una aplicación con muchas dlls?

¿Una desventaja con muchas DLL? No
¿Una desventaja con demasiadas DLL? Por supuesto.

Entonces, ¿cuántos son demasiado?

Un ensamblaje es un medio de organización, como espacios de nombres y clases. Los espacios de nombres definen límites lógicos, ensambla límites físicos.

Debe intentar mantener los ensamblajes coherentes y verlos como módulos del sistema.

Y sí, habría un problema de rendimiento (pequeño) si tuviera cientos de ellos.Pero con 40, no veo un problema.

Answer 2

Mantenimiento - no, el rendimiento - sí. Cuantos más montajes necesite cargar, más lenta será la aplicación. Para cada ensamblaje que se debe cargar en AppDomain, el cargador necesita realizar una serie de verificaciones.

Answer 3

Los tipos de problemas que empeoran con más archivos DLL son:

• tiempos de construcción: el compilador se ejecuta una vez para cada DLL y DLL se debe copiar en y desde el directorio de salida
• Tiempos de carga: cada archivo DLL debe ser cargado por separado por Windows, aunque los archivos DLL se cargan por demanda, por lo que normalmente incurrirá en costos solo para las piezas que usa
• Rebasing: cuantos más archivos DLL hav e, mayor es la probabilidad de que dos colisionen en la memoria virtual. Esto no representa un problema, porque Windows puede volver a basar uno de ellos, pero el proceso de reescalado lleva tiempo, y Windows debe cargar las páginas DLL afectadas del disco con anticipación. Rebase no suele afectar mucho a las DLL administradas.
• Visual Studio sobrecarga: una DLL = = un proyecto más trabajo para el IDE

El consejo que sigo es utilizar DLL para organizar su despliegue, y espacios de nombres de organizar el código. Si encuentra que siempre libera un conjunto determinado de archivos DLL juntos, también podría fusionarlos.

Answer 4

La separación de dominios funcionales independientes en archivos DLL individuales generalmente es buena cosa. Ayuda a introducir el potencial de reutilización y ayuda a mitigar la introducción de un acoplamiento inadecuado entre las implementaciones internas de las clases.

Sin embargo, hay desventajas a la introducción de varios ensamblados como parte de un sistema:

1. se tarda más tiempo en cargarse, verificar, y múltiples conjuntos de JIT. Sin embargo, esto rara vez es un problema, y ​​en general no debería ser su principal preocupación al decidir cómo particionar la funcionalidad de una aplicación.
2. No es prudente actualizar una aplicación implementando cambios dentro de un solo ensamblaje. A menudo, dividir una aplicación en archivos DLL separados crea la impresión de que es posible corregirlo o mejorarlo reemplazando solo algunos de sus ensamblajes. Si bien es ciertamente posible, puede introducir errores sutiles si hay cambios en los efectos secundarios o comportamientos no documentados de las clases y métodos en esos ensamblajes.
3. Puede ser más difícil entender un sistema que está dividido en demasiados conjuntos. Herramientas como ReSharper y CodeRush tienen algunas limitaciones cuando se analiza el código dividido en varios ensambles.
4. Puede alentar a los desarrolladores a hacer más tipos públicos de lo que deberían. Dado que solo los tipos públicos pueden ser consumidos y heredados por otros ensamblajes, un proyecto de ensamblaje múltiple puede generar más tipos públicos de los deseados.

Answer 5

No olvides ILMerge. Funciona bastante bien si desea las múltiples DLL para el desarrollo (proyectos diferentes), pero un EXE para la implementación (más rápido de cargar, más fácil de implementar).

La desventaja de ILMerge es que fallará en algunos escenarios de carga dinámica, por ejemplo, crear una instancia de un tipo por nombre (cadena). Entonces, ILMerge puede o no ser factible, dependiendo de su proveedor de IoC.