Antipatrones del uso de contenedores de IoC. ¿Por qué los contenedores IoC son tan complejos y se usan de manera tan "elegante"?

Question

Estoy seriamente comenzando a pensar que el uso del contenedor IoC provoca la creación de soluciones sobrediseñadas (al menos me provoca intentar usar varias funciones innecesarias :).

que es el momento para sincronizar mi lista antipatrones "IoC" con la comunidad de uno ..

Mi corta experiencia dice que es absolutamente suficiente para llamar al método Resolve una vez por aplicación en el arranque para resolver algunos conjuntos unitarios de infraestructura e iniciar con la "fábrica de objetos transitorios" que podría producir nuevas "fábricas de grano de por vida más pequeñas". Incluso para hacer que esas fábricas sean seguras (por ejemplo, crear una instancia por hilo) es tan fácil de lograr agregando 10 líneas de código en fábrica ... Aún así, las fábricas son mucho más simples que "la integración de la biblioteca con la herramienta IoC". ¿Interceptación? Solo cree sus propios contenedores ... ¿Administradores de tiempo de vida/estrategias de dependencia/contenedores principales? Llame a Resolver solo una vez al programa de arranque y no pensará en eso.

¿Podría ayudarme a comprender por qué los desarrolladores llaman a Resolver varias veces en diferentes capas de aplicaciones (pasando el contenedor o delegando a un contenedor) y luego tienen muchas cosas en qué pensar? Realmente me preocupa que me pierda algo.

Answer 1

que he encontrado a alguien que posiblemente me podría entender :)

Constructor over-injection anti-pattern

Answer 2

Otros antipatrón en mis ojos está empujando a la inicialización del contenedor bootsrapper continuación real "más profundo".

Por ejemplo Unity and WCF recommendations

programa previo en aplicación WCF es el constructor de servicio, a continuación, sólo hay que poner la inicialización del contenedor para el constructor. No entiendo las razones para recomendar la programación de comportamientos de servicio y la fábrica de host de servicio de cliente: si desea tener el programa de arranque de contenedor de IoC, es absurdo, si necesita tener una implementación de contrato de servicio de contenedor de IoC. simplemente cree una segunda implementación de contrato de servicio "IoC container free".

Answer 3

Leer This

Es evidente que algo anda mal. La nueva biblioteca no debe traer código complejo adicional.

Answer 4

Algún tipo de IoC son anti-patrones o pueden ser en algunos casos. Por ejemplo, el service locator antipattern. Pero si está utilizando la inyección de constructor al principio de la aplicación (y solo allí), entonces debería no dar lugar a un antipatrón.

Inyectar una interfaz de contenedor DI en una clase es un uso incorrecto de la inyección de constructor. Si DI no es parte de la lógica comercial de su clase, no debe saber ni depender del contenedor DI ni debe depender de IKitchen. Está bien inyectar su contenedor DI en algún tipo de ayuda o servicio que trabaje junto con su contenedor de inyección de dependencia, porque su propósito es trabajar con o alrededor del contenedor DI. Los ejemplos en los enlaces que usted proporciona son uso indebido de IoC. No significa que la IoC en general sea un antipatrón.

Creo que la pregunta correcta sería "¿Puede la inyección del constructor ser un antipatrón?". Hasta el momento, nunca he enfrentado ninguna situación ni he visto ningún ejemplo donde fuera, así que diría "no", hasta que me enfrente a tal situación.

Answer 5

Cuando no estaba claro para mí cómo usar un contenedor IoC, decidí dejar de usarlo, porque pensé que era solo una complicación sobre la inyección de dependencia simple.

Es verdad que incluso sin IoC es posible caer en los casos de sobreinyección. Hace un tiempo leí algunas publicaciones del autor de ninject que me abrieron la mente.

Como ya sabe, el inyector debe usarse solo dentro de la raíz de contexto. Sin embargo, para evitar las sobreinyecciones, decidí introducir una excepción de la regla para las fábricas inyectadas.

En mi marco, las fábricas (y solo las fábricas) pueden usar el contenedor del inyector. Las fábricas se agrupan en el contenedor en la raíz de contexto y, por lo tanto, se pueden inyectar. Las fábricas se vuelven dependencias válidas y se utilizan para crear nuevos objetos dentro de otros objetos, utilizando el contenedor del inyector para facilitar la inyección de dependencias.