(automática) Inyección de dependencias Encuadernación Mecanismos

Question

Los dos mecanismos comunes para la creación de enlaces de inyección de dependencia, tales como a través de un recipiente IOC, es de una configuración de XML o un bloque de código imperativo. En estos casos, el par de valores clave es explícito (es decir, clave = tipo solicitado, valor = tipo devuelto).

Todavía hay un tercer enfoque "heurístico" donde un contenedor de aplicación/IOC recibe solo claves [IMyClass] y el contenedor refleja un conjunto de dependencias de conjunto de aplicaciones para encontrar todas las clases concretas con nombre coincidente [MyClass] . Dicho de otra manera, los valores de "tipo de devolución" se descubren en lugar de declararse.

Lo que me gustaría saber es doble:

1. Qué contenedores COI (u otras herramientas de unión a finales de los años) permiten el enfoque heurístico? ¿Este enfoque tiene un nombre más común?
2. ¿Existen otras técnicas de encuadernación, además de las tres que he enumerado, que se utilizan en la práctica?

Answer 1

Esto se llama Configuración basada en la convención o Autoregistro y es compatible con estos.NET DI Contenedores:

• Castle Windsor
• StructureMap
• Autofac

Los mecanismos más comunes de configuración utilizados para DI contenedores se

• XML
• Código de configuración como
• Convención de base de configuración

Un cuarto, pero poco común, el enfoque es utilizar atributos. El Managed Extensibility Framework es el ejemplo más destacado de este enfoque, que es más común en Java.

Answer 2

Hice generalmente lo que usted describe como un paso personalizado en la configuración. AFAIK no hay ningún contenedor que ofrezca una estrategia de este tipo (y en mi opinión no es una parte del contenedor, sino un elemento de configuración que debería ser externo a la responsabilidad del contenedor).

Answer 3

Lo que usted llama un enfoque "heurístico" es lo que llamo convenciones. La mayoría de los contenedores IoC le permiten anular la forma en que resuelven los enlaces, lo que significa que puede introducir cualquier convención que desee. No hay tales convenciones predeterminadas que yo sepa. Por el contrario, la mayoría de los contenedores no hacen nada por defecto; es su trabajo decirles cómo resolver tipos, ya sea a través de un archivo de configuración o a través de un código.

Un ejemplo de una convención personalizada que encuentro es bastante común que le ahorra muchas declaraciones: si el tipo solicitado es un tipo de interfaz que comienza con "I" y termina con "Servicio" y luego intenta crear y resolver un tipo con el mismo nombre aparte del "yo". Esto resolver nombres como IFooService a FooService automágicamente. Además, se puede introducir la lógica para decidir sobre los diferentes servicios en diferentes contextos con bastante facilidad, y que puede manejar vidas instancia de servicio en un lugar común.

Ya que se puede anular cómo se unen la mayoría de los contenedores IoC, puede introducir otros comportamientos también. En general, sin embargo, en realidad hay dos opciones:

1. Configurar en tiempo de ejecución (a través de archivos de configuración, tales como archivos XML)
2. Configurar en tiempo de compilación (ya sea a través de una API declarativa DSL o similar a través de la costumbre convenciones u otra forma de lógica personalizada)

Answer 4

Desde que he usado StructureMap un poco sabría cómo hacer tal cosa con ese contenedor: sería básicamente ser un Convenio sobre el registro personalizado (a partir de inicialización o un registro, entra en el bloque de exploración-lambda y encontrar el método de la "Convención").

Permite que usted mire los tipos reflejados y luego insertarlos en la configuración del contenedor como mejor le parezca. Debe permitir lo que estás tratando de hacer.