c# - type - unity di container

Sin entender dónde crear Contenedores de IoC en la arquitectura del sistema

Question

Digamos que tengo los siguientes 4 ensamblajes .net:

1. Interfaz de usuario de Winforms
2. Lógica de negocios
3. Acceso a datos de SQL Server (implementación de un IRepository)
4. Interfaces comunes (definición de IRepository, etc.)

Mi lógica de negocios (2) realiza llamadas a la capa de acceso a datos (3) a través de IRepository (definido en 4) utilizando la inyección de dependencia del constructor. Sin embargo, cuando cito un objeto comercial, necesito pasar un repositorio real. Hago esto haciendo que una clase singleton en mi capa de lógica empresarial devuelva el objeto concreto actualmente en uso que implementa IRepository. Estoy llegando a la conclusión de que esto es algo malo, ya que mi capa de lógica empresarial ahora tiene que hacer referencia a 3 y a 4.

Creo que necesito un Contenedor de IoC, pero la pregunta es ¿dónde lo creo / lo puse, ya que parece que donde quiera que creo esto (1 - UI)? también deberá contener una referencia a 3 (Acceso a datos de SQL Server). ¿No solo estoy moviendo el problema en lugar de lograr el desacoplamiento real?

¿Creo el contenedor IoC en la interfaz de usuario? O exponerlo a través de otro ensamblaje nuevo.

(Estoy usando C #, .net 3.5 y AutoFac)

Gracias.

Answer 1

El nivel superior es un camino por recorrer (UI, como dijo Rinat).

Ahora, en cuanto a las referencias, la forma más simple es simplemente revisar todos los ensamblajes en la carpeta actual y usar alguna convención para obtener los servicios. Los atributos funcionan bien, poner clases de registrador en cada conjunto funciona bien, lo que más le convenga. El código para extraer todo debería estar en un ensamblaje separado, a menos que su framework IoC ya lo haga.

Answer 2

La distinción del módulo y los "ámbitos" definidos por los módulos existen principalmente en tiempo de compilación. En el tiempo de ejecución, todo es un gran desastre;) Esto es utilizado por la mayoría de los contenedores IOC y realmente no les importa dónde se encuentran. El contenedor IoC para una aplicación web generalmente se creará en el nivel más externo (muy cerca del contenedor web).

Answer 3

El contenedor de IoC generalmente se debe crear en el proyecto de host (punto de entrada de la aplicación). Para la aplicación Windows.Forms que es el proyecto exe.

En general, en soluciones simples (menos de 10 proyectos), solo un proyecto de host debe tener una referencia a la biblioteca de IoC.

PD: Estructuración de aplicaciones .NET con Autofac IoC

Answer 4

Al registrar componentes hay varias posibilidades:

1. Registro en el código:

   • directamente
     Problema: tienes que hacer referencia a todo (estás aquí)
   • indirectamente
     Problema: averiguar qué debe registrarse
     Solución:
     1. usar atributos
     2. utilizar la interfaz de marcador como IService
     3. usar convenciones (ver StructureMap)

2. Registro con archivo de configuración:

   • deja que el contenedor haga todo
   • lea el archivo usted mismo

Answer 5

Es cierto que podrías crearlo en cualquier lugar, pero yo presentaría una capa adicional, llamémoslo 3.5.

Su 3 actual sería donde reside su IoC para el acceso a datos; esto se convertiría en un contenedor para su DAL real. En función de su configuración, 3 crearía un repositorio simulado o uno concreto.

Por lo tanto, 2 siguen siendo referencias 3, pero es solo una interfaz para el DAL real que se configura a través de su marco de trabajo de IoC.

Alternativamente, podría hacer rodar su propia IoC ''el-cheapo'' - cambiar su Singleton grande y feo a una puerta de enlace estática - Resumen del contenedor de IoC detrás de un singleton - ¿Hacerlo mal?