Dependency Injection en una aplicación n-tier?

Question

que tienen una aplicación de servicio de .NET de 3 niveles, que sigue el enfoque estándar:

Frontend -> Object Model/Business Logic -> Data Access 

Estoy tratando de aprender acerca de la inyección de dependencia a lo largo del camino, y hasta ahora lo he encontrado muy bien (usando Autofac) . Cada uno de los 3 niveles necesita crear una variedad de objetos, a veces con configuración extra/etc. Parece que el contenedor DI debería ser lo ideal para resolver esto, pero estoy teniendo algunos problemas para ver dónde debería vivir en relación con el resto del sistema.

Actualmente tengo una clase en la interfaz que configura el contenedor DI. Básicamente es un gran grupo de código que dice container.Register<SomeType>() y así sucesivamente.

El problema es que está configurando el contenedor para los 3 niveles y, por lo tanto, debe tener un conocimiento bastante invasivo de la capa de acceso a los datos. Tener un código en mi frontend con tal conocimiento hace saltar las campanas de alarma en mi cabeza, ya que el punto de separar la aplicación en niveles es evitar esta situación exacta.
Esto también empeora por el hecho de que mi capa de acceso a datos no es solo un servidor SQL que es un tonto cubo de bits, sino que está compuesto por muchas interoperaciones COM complejas y llamadas P/Invoke, por lo que tiene un gran impacto la configuración DI

He pensado en dividirlo, quizás tener un contenedor por nivel o tener una clase de "Configuración" en cada nivel que hable con el contenedor DI global para registrar sus propios bits, pero no estoy seguro si eso causa más problemas de los que resuelve ...

Realmente agradecería que alguien pudiera compartir sus experiencias en el uso de DI con aplicaciones de varios niveles.

Gracias, Orion.

Answer 1

Esto depende de si tiene tres niveles (separación física) o si todas sus capas lógicas se implementan juntas. Si el frontend está separado de su BL y se comunica a través de un servicio web o WCF, el frontend y el backend necesitan sus propios contenedores porque se ejecutan en procesos separados o máquinas separadas. Los contenedores solo registrarían sus propios componentes y las interfaces de la capa 'siguiente'.

Por otro lado, si todas las capas se ejecutan en el mismo proceso, entonces solo debe tener un contenedor. El contenedor se inicializaría y alojaría en el punto de partida de la aplicación, como global.asax para una aplicación web.

El problema con el host del contenedor al conocer muchas de las diferentes partes del sistema podría resolverse al no registrar las clases una por una, sino que registrar todos los tipos en un ensamblaje. De esta forma, no necesita referencias sólidas a todos los ensambles en su solución solo para configurar el contenedor. Ejemplo de cómo se puede hacer eso con Castle Winsdor:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll")); 
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));