¿Inyección de dependencia en una aplicación de n niveles?

Question

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

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

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

Actualmente tengo una clase en el frontend que configura el contenedor DI.Básicamente es un gran montón de código que dice container.Register<SomeType>() etcétera.

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 datos.Tener un código en mi interfaz con tal conocimiento activa las alarmas en mi cabeza, ya que el objetivo de separar la aplicación en niveles es evitar esta situación exacta.
Esto también se ve empeorado 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 interoperabilidad COM compleja y llamadas P/Invoke, por lo que tiene un gran impacto en la DI. configuración.

He pensado un poco en dividirlo: tal vez tener un contenedor por nivel o tener una clase de "Configuración" en cada nivel que se comunique con el contenedor DI global para registrar sus propios bits, pero no estoy seguro si eso causará 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, Orión.

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, entonces el frontend y el back-end 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 están ejecutando en el mismo proceso, entonces solo debería tener un contenedor. El contenedor se inicializaría y se alojaría en el punto de partida de la aplicación, como global.asax para una aplicación web.

El problema de que el host del contenedor conozca muchas de las diferentes partes del sistema podría resolverse no registrando las clases una por una, sino registrando todos los tipos en un ensamblaje. De esa manera, no necesita referencias fuertes a todos los ensamblajes 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"));