Recursos para diseñar la estructura .dll

Question

Acabo de salir de una reunión de diseño y me hicieron una pregunta acerca de dónde obtuve una de mis ideas sobre cómo estructurar algunos .dlls de un proyecto que estamos construyendo. Para ser honesto, no tengo idea de dónde está " idea " Venía de eso solo me parecía un conocimiento natural. Sin embargo, sería útil si pudiera respaldar estas opiniones con un análisis documentado.

¿Alguien sabe de algún recurso que explique explícitamente los diferentes mecanismos para estructurar ensamblados / módulos / fuente?

ACTUALIZACIÓN:

Bueno, la idea no era nada especial. Estábamos discutiendo una capa de abstracción para algún hardware, por lo que la " aplicación " que consume estos servicios podría ser (tipo de) plataforma independiente. Anteriormente hemos tenido una interfaz .dll que declara las interfaces que requiere la aplicación y una implementación .dll que las implementa para la única plataforma que hemos tenido hasta ahora. Ahora tenemos dos plataformas pero son muy parecidas. Para evitar que las interfaces .dll se contaminen o algún escenario horrible en el que las implementaciones se refieran entre sí, simplemente sugerí que creamos otro .dll que se ubique entre las interfaces y specificplatform.dlls donde pueden existir implementaciones abstractas comunes.

Answer 1

Si tiene una oportunidad, eche un vistazo al libro de Robert C. Martin:

Principios, patrones y prácticas ágiles en C # (esta es la nueva versión dirigida específicamente a .Net)

Hay un capítulo dedicado al diseño de componentes que (probablemente) responde a su pregunta.

En resumen, y después de leer ese libro, siempre recomiendo separar los componentes según estos criterios:

• Los ensamblajes son unidades o se reutilizan : si hay clases que deben usarse juntas, van en el mismo ensamblaje.

• Los ensamblajes son unidades de cambio : si hay clases que no tienen que cambiar por el mismo motivo, probablemente no deberían estar en el mismo ensamblaje.

• Los ensamblajes son unidades de implementación : si hay clases que deben implementarse físicamente en el mismo lugar, probablemente deberían ir en el mismo ensamblaje.

Por supuesto, estas son solo heurísticas y no recetas. Finalmente, debe decidir la cantidad de cada una de las tres heurísticas de diseño que necesita en función de los objetivos arquitectónicos de su aplicación (específicamente los objetivos arquitectónicos para la implementación y la evolución / modificación).