¿Por qué crear archivos DLL en lugar de compilar todo en un ejecutable grande?

Question

Vi y he hecho muchos productos pequeños donde un mismo programa se separa en un ejecutable y varias DLL, y esas DLL no son solo bibliotecas compartidas hechas por otra persona, sino bibliotecas que se hacen exclusivamente para este software, por el mismo equipo desarrollador. (No estoy hablando aquí de productos a gran escala que solo requieren cientos de DLL y los comparten extensivamente con otros productos).

Entiendo que separar el código en varias partes, cada una compilando en una DLL separada, es bueno desde el punto de vista de un desarrollador. Significa que:

• Si un desarrollador cambia un proyecto, tiene que volver a compilar solo este y los dependientes, que pueden ser mucho más rápidos.
• Un proyecto puede realizarlo un único desarrollador en un equipo, mientras que otros desarrolladores solo usarán las interfaces proporcionadas, sin entrar en el código.
• Las actualizaciones automáticas del software a veces pueden ser más rápidas, con un impacto menor en el servidor.

Pero, ¿y el usuario final? ¿No es malo entregar una pieza de software compuesta de un EXE & varias DLL, cuando todo se puede agrupar? Después de todo:

• El usuario no puede siquiera entender lo que son esos archivos y por qué se llenan de memoria en su disco duro,
• El usuario puede querer mover un programa, por ejemplo guardarla en una unidad flash USB . Tener un ejecutable grande hace las cosas más fáciles,
• La mayoría del software anti-virus comprobará cada DLL. Comprobar un ejecutable será mucho más rápido que el ejecutable más pequeño y docenas de bibliotecas.
• El uso de DLL hace que algunas cosas sean más lentas (por ejemplo, en .NET Framework, debe encontrarse una biblioteca "buena" y marcada si está firmada),
• ¿Qué ocurre si se elimina una DLL o se reemplaza por una versión incorrecta? ? ¿Cada programa maneja esto? ¿O se cuelga sin siquiera explicar lo que está mal con eso?
• Tener un ejecutable grande tiene some other advantages.

Así que ¿No es mejor, desde el punto de vista de los usuarios finales, para programas pequeños/medianos, entregar un ejecutable grande? Si es así, por qué no hay herramientas que permitan hacerlo fácilmente (por ejemplo, una herramienta mágica integrada en IDE comunes que compila toda la solución en un ejecutable, no cada vez, por supuesto, pero a pedido o durante el despliegue).

---

Esto es de alguna manera similar a putting all CSS or all JavaScript files into one big file para el usuario. Tener varios archivos es mucho más inteligente para el desarrollador y más fácil de mantener, pero vincular cada página de un sitio web a dos archivos en lugar de docenas optimiza el rendimiento. De la misma manera, CSS sprites son terribles para los diseñadores, ya que requieren mucho más trabajo, pero son mejores desde el punto de vista de los usuarios.

Answer 1

Es una desventaja
(te has dado a ti mismo ya;))
Para la mayoría de los proyectos, el cliente no le importa cuántos archivos se instalan, pero que le importa cuántas características se completan en el tiempo . Hacer la vida más fácil para los desarrolladores también beneficia al usuario.

Algunos más razones para

Algunas bibliotecas de DLL no juegan bien juntos en la misma estructura, pero se pueden hacer a comportarse de una DLL (por ejemplo, un archivo DLL puede utilizar WTL3, el otro requiere WTL8) .

Algunas de las DLL pueden contener componentes para ser cargados en otros ejecutables (ganchos globales, extensiones de shell, complementos de navegador).

Algunas de las DLL pueden ser de terceros, solo están disponibles como DLL.

Puede haber reutilización dentro de la empresa, incluso si solo ve un producto "público", podría usarse en una docena de proyectos internos que usan esa DLL.

Algunas de las DLL pueden haberse creado con un entorno diferente que no está disponible para todos los desarrolladores de la empresa.

EXE independiente vs. producto instalado
Muchos productos no funcionará como ejecutable independiente de todos modos. Requieren instalación y el usuario no toca cosas que no debe tocar. Tener uno o más binarios no importa.

El tiempo de construcción de Impacto
Tal vez usted subestima el impacto de los tiempos de construcción y mantenimiento de una versión estable para grandes proyectos. Si una compilación demora incluso 5 minutos, podría llamar epistemáticamente a eso "hacer que los desarrolladores piensen en el futuro, en lugar de jugar hasta que parezca que funciona bien". Pero es una persona que come mucho tiempo y crea una distracción seria.

El tiempo de compilación de un solo proyecto es difícil de mejorar. Trabajando en VC9, la paralelización de compilación dentro de un proyecto es inestable, como lo es el enlazador incremental. Los tiempos de enlace son especialmente difíciles de "optimizar" con máquinas más rápidas.

desarrollador Independencia
Otra cosa que puede subestimar.
Para usar un archivo DLL, necesita un .dll y un .h. Para compilar y vincular el código fuente, generalmente necesita configurar directorios de inclusión, directorios de salida, instalar bibliotecas de terceros, etc. Realmente es un dolor.

Answer 2

Creo que su punto general acerca de considerar cuidadosamente el empaque final de los entregables está bien hecho. En el caso de JavaScript, dicho embalaje es posible, y con la compresión hace una diferencia significativa.

Answer 3

Sí, es mejor en mi humilde opinión - y siempre uso enlaces estáticos por exactamente las razones que das, siempre que sea posible. Muchos de los motivos por los que se inventó la vinculación dinámica (por ejemplo, salvar la memoria) ya no se aplican realmente. OTOH, hay razones arquitectónicas, por ejemplo, arquitecturas de plugins, por las que la vinculación dinámica puede ser preferible a la estática.

Answer 4

Hecho muchos proyectos, nunca conocí a un usuario final que tiene algún problema con algunos archivos dll que residen en su caja.

Como desarrollador, yo diría que sí, podría importar. Como usuario final que se preocupa ...

Answer 5

Sí, a menudo puede ser mejor desde el punto de vista del usuario final. Sin embargo, los beneficios para el desarrollador (y el proceso de desarrollo) que menciona a menudo significan que una empresa preferirá la opción rentable.

Es una característica que muy pocos usuarios apreciarán, y que tendrá un costo de entrega no trivial.

Recuerde que en StackOverflow somos usuarios "por encima de la media". ¿Cuántos miembros de la familia (no geek) y amigos tiene que realmente valor la capacidad de instalar su software en una memoria USB?

Answer 6

Las grandes ventajas para dll están relacionadas con la introducción de fronteras y la independencia.

• Por ejemplo, en C/C++ solo están visibles los símbolos exportados. Imagina un módulo A con una variable global "escala" y un módulo B con otra variable global "escala" si pones todo junto vas a desaster; en este caso, un dll puede ayudarte.

• Puede distribuir esos dll como componente para clientes sin exactamente las mismas opciones de compilador/enlazador; y esta es a menudo una buena manera de hacer interoperaciones de lenguaje cruzado.