¿Debo crear DLL para la modularidad?

Question

Estoy trabajando en la creación de una aplicación que analizará los artículos de MSDN para la metainformación, como el título del artículo y otros artículos que están en la misma colección. Esta aplicación también tiene un front-end GUI.

Estoy interesado en hacer este programa más modular separando el front-end del back-end y el back-end en dos partes, una que maneja la recuperación y el análisis general de un documento HTML y uno eso hace un análisis más específico relacionado con MSDN. La idea es que esto permita que las IU personalizadas se incluyan en el back-end y permitan que la aplicación pueda analizar otros sitios (quizás los resultados de búsqueda de Google) tan solo conectando una DLL diferente.

Según tengo entendido, normalmente crearía DLL para compartir código en diferentes aplicaciones. Sin embargo, en este caso, solo estoy buscando modularidad para esta aplicación en particular. ¿Sigue siendo apropiado crear DLL en este caso? ¿O debería considerar una opción diferente, como simplemente agrupar todas las clases en un solo conjunto?

Debo notar que soy relativamente nuevo en la programación, por lo que incluso si la respuesta es "no", entonces este será un buen ejercicio para aprender. Si ese es el caso, me gustaría saber si este ejercicio se debe modificar de todos modos para hacerlo más apropiado.

Answer 1

Creo que su idea de usar DLL en esta situación es una buena idea. No hay un costo adicional apreciable en el uso de DLL (posiblemente un poco más de costos de inicio como máximo). E incluso si actualmente solo está pensando en usarlos en esta aplicación, no está de más hacer planes para futuros cambios. Siempre hay una buena posibilidad de que las DLL se puedan usar con poca o ninguna modificación en otra aplicación si es necesario.

Además, dividirlo en archivos DLL separados para la modularidad podría incluso ayudar con el proceso de diseño y desarrollo. Hace que compartir datos globales sea más difícil (y eso es probablemente algo bueno). Si todo está en una sola asamblea monolítica, puede haber cierta tendencia a simplemente obtener algunos datos de otro lugar. Si esos datos viven en otra asamblea, es menos probable que esa práctica potencialmente mala ocurra. Puede forzar al desarrollador a reconsiderar cómo resolver problemas.

Answer 2

Las DLL pueden ayudar con el mantenimiento de su aplicación. Si tiene actualizaciones futuras y/o correcciones de errores, puede actualizar archivos DLL específicos en lugar de toda la aplicación. Esto también ayudará a reducir el área de su superficie de prueba.

Durante el desarrollo, también será un poco más fácil anular ciertas clases/DLL y cambiar las DLL actuales más adelante una vez desarrolladas.

No me volvería loco y pondría cada clase en su propia DLL. Desde un nivel alto debería haber una agrupación clara de clases que deberían estar juntas.

Answer 3

Hay varias ventajas para hacer una DLL:

• el DLL se puede cambiar independientemente del programa llamante (front-end)
• el DLL se puede distribuir por sí mismo, independientemente del problema de llamadas (front-end)
• si varios software que se ejecuta al mismo tiempo utilizan la misma DLL de la huella de memoria será menor

también viene con un costo:

• no se puede utilizar el sistema de herencia simple de extender las clases DLL
• uso compartido de datos global es todavía posible pero es más difícil (algunos pueden decir que esta fuerza mejor diseño, pero sigue siendo una limitación) las pruebas
• unidad de código incluido en un archivo DLL es más difícil
• existen problemas de instalación (el archivo DLL se tienen que colocar en lugares especiales registradas, dependiendo de cómo lo usa)

Pero el punto principal con respecto a la modularidad es que DLL es sigue siendo una medida a medias. Incluso si ignoramos los costos, no es mucho mejor que una lib o incluso simplemente reutilizar las clases existentes. Las principales ventajas son para los revendedores, en realidad no para los desarrolladores de software, excepto si se espera que contribuyan terceros. Y las funciones llamadas todavía se están ejecutando en el mismo proceso que el programa principal.

Si desea un corte limpio real para la modularidad, puede utilizar una arquitectura real de múltiples niveles con procesos separados para front-end y back-end y una capa de comunicación entre ellos (por ejemplo, sockets TCP). Eso suele ser más versátil y más robusto, y no mucho más complejo cuando se hace lo suficientemente temprano en la vida del proyecto.