DAL -> BLL <- GUI + composición raíz. ¿Cómo configurar enlaces DI?

He hecho una aplicación de tres capas con refrences yendo como se describe en esta respuesta :

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app 

Para que esto funcione con dependency injection, veo algunas opciones:
1. Agregue una referencia a DAL desde la aplicación web para poder configurar los enlaces al inicio de la aplicación.
2. Use un contenedor con configuración xml
(3. Utilice la reflexión para cargar el ensamblado dal y encuentre tipos)

La opción 1. es fácil y también hace que DAL.dll se copie a la papelera, pero luego, de repente, reintrodujo la referencia de la que trabajé tan duro para deshacerme. A los repositorys ahora se puede acceder directamente. Las opciones 2 y 3 parecen innecesariamente complejas.

¿No hay otra manera?

Divida la aplicación ASP.NET MVC en dos:

  • Una parte es su aplicación ASP.NET MVC original, pero sin ninguna lógica adicional. Simplemente mantenga la raíz de composición y sus vistas (.aspx, etc.) en este proyecto. Dado que esta es la raíz de composición, puede tener referencias a todos sus otros proyectos. Sin embargo, dado que toda la lógica se habría extraído, ahora se trata de un objeto humilde , por lo que está bien tener todas las referencias en este nivel.
  • Extraiga toda la lógica (controladores, etc.) en un proyecto de modelo de aplicación , que simplemente sería un proyecto de biblioteca normal (.dll) que haga referencia a los binarios de ASP.NET MVC. Este proyecto necesitaría hacer referencia al BLL para llegar a las interfaces, pero está bien. Sin embargo, tanto el Modelo de Aplicación como el BLL están efectivamente protegidos del DAL.

La superposición resultante se vería así:

  • Aplicación ASP.NET MVC
  • Modelo de aplicación
  • BLL
  • DAL

La respuesta de Mark Seemann me dio la idea para esta variante:

 DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app ^------------------------^--------- Composition Root <-------´ 

Esto tiene la intención de ilustrar que, en lugar de dejar que el proyecto web haga referencia al DAL, hace referencia a un proyecto raíz de composición separado que hace referencia tanto a DAL como a BLL. La composición-raíz-proyecto tiene una sola clase con un método que define las consolidaciones. Le da estos beneficios adicionales:

  • Solo tres capas Cuatro capas serían una venta difícil en el equipo.
  • El acoplamiento flojo está asegurado. No es posible acceder al DAL desde el código de vista.
  • Mejor soporte de herramienta. Los controladores permanecen en la ubicación estándar, por lo que se puede acceder a "Agregar controlador" en el menú de contexto y las vistas faltantes se resaltan en el código del controlador. Además, no es necesario configurar o escribir una fábrica de controladores personalizada.

No veo grandes inconvenientes.

Solo ve con la Opción 1.

Solo porque tenga una referencia al ensamblaje no significa que haya roto el SoC.

El proyecto web aún no sabe nada sobre las implementaciones subyacentes, solo la interfaz.

El Proyecto web es el “agregador” de las capas inferiores, por lo que tiene sentido que las conozca para poder configurarlas.

Divido el proyecto MVC en dos aproximadamente como se describe en Mark Seemans Answer.

La aplicación MVCA es un objeto humilde y requiere referencias a todo, pero no tiene ningún código MVC, aparte de global.asax (que necesita) y web.config (que parece querer).

El proyecto MvcUI solo hace referencia a las interfaces y usa la dependency injection.

Si coloca los dos proyectos (archivos .csproj) en el mismo directorio, las carpetas Contenido, Controladores, Modelos, Secuencias de comandos y Vistas se encuentran todos en el mismo lugar, por lo que todas las herramientas funcionan.

La imagen de la solución a continuación muestra la idea.

MVC Composition Root Solution Explorer

La estructura del directorio se ve algo como esto

Estructura de directorio raíz de composición MVC

Y terminas con un gráfico de Dependencia como este

Gráfico de dependencia de la raíz MVC Composition

Recientemente estaba siguiendo lo mismo y pensé en el MEF (Managed Extensibility Framework). Con la ayuda de MEF y la reflexión, puede deshacerse de esa referencia de DAL / Unidad de trabajo desde la raíz de su composición y no necesita tener proyectos de 2 mvc como se discutió anteriormente.