IoC Container Aplicabilidad / Escenario Demostración?

Question

Muchas personas en el espacio .NET han elegido Castle Windsor y lo están implementando en sus proyectos, y durante el último año he estado luchando por descubrir por qué los contenedores IoC parecen ser tratados como los mejores en general. practicar " ;? He leído MUCHOS resúmenes y explicaciones breves sobre los por qué de Windsor y similares, pero cada uno de ellos es realmente abstracto y no parece ser práctico para la mayoría de los proyectos que he tocado, pero últimamente he estado encontré muchos proyectos que usan Windsor y no entiendo por qué.

C # /. NET soporta inherentemente codificación basada en interfaz, objetos abstractos, delegados y eventos. Uno puede implementar IoC directamente desde el lenguaje central y, utilizando Reflection y similares, crear instancias desconocidas que implementen interfaces conocidas, sin recurrir a las bibliotecas de contenedores de IoC.

Al aplicar el YAGNI / AYGNI (¿Vas a necesitarlo?) Siento que Windsor ha sido usado en exceso. Ciertamente puedo ver los beneficios de un contenedor de IoC, pero creo que estos beneficios tienen el costo de dependencias y metadatos adicionales (atributos y métodos específicos del contenedor de IoC llamados en el código central, archivos .config dispersos por todas partes, app.config / web.config lleno de etiquetas de enlace que hacen que el archivo .config sea más difícil de editar, etc.), así que estoy tratando de descubrir la compensación.

Dicho esto, acepto la posibilidad de hacer ALL estas observaciones / declaraciones sobre ignorancia, ya que nunca he estado muy involucrado en un proyecto que utilizara Windsor u otro contenedor de IoC biblioteca. Lo que realmente necesito es que alguien demuestre un "promedio". o "típico" proyecto donde se usó una biblioteca contenedor de IoC y por qué se supone que esta es una `` mejor práctica '' cuando para mí parece que hace que un proyecto limpio sea desordenado con dependencias y metadatos.

Si alguien sabe de publicaciones de blog, artículos o libros que me llenen, sería genial.

(No estoy discutiendo por discutir el bien, sino porque realmente quiero que me eduquen sobre si debo educarme en los contenedores de IoC).

Answer 1

Parece que quieres la respuesta a esta pregunta

Obviamente, si el sistema es tan difícil de configurar como usted dice, entonces no valdrá mucho la pena mantenerlo. Eso es algo importante a tener en cuenta al usar una nueva tecnología. A veces, las cosas viejas y aburridas son mucho mejores por este factor.

Castle Windsor usa el reflejo mismo, por lo que es realmente un envoltorio para hacer las cosas de la manera que quieras de todos modos. Si puede desarrollar un sistema que sea más fácil de usar que CW, debería hacerlo, incluso si le cuesta en el tiempo inicial de inicio. Ese costo se compensará con la curva de aprendizaje de CW en primer lugar, por lo que no será como reinventar la rueda.

Ellos se dicen que IoC no es adecuado para proyectos pequeños,

  

Además, dependiendo del tamaño y   complejidad del proyecto, un IoC   El contenedor puede ser excesivo. Preferir   Úselo en proyectos medianos a grandes.

Answer 2

No es una respuesta directa a su pregunta porque no estoy familiarizado con Castle-Windsor, y no soy un experto en IoC, pero por mi experiencia con la versión Java de Spring puedo decir que (estoy hablando de Spring aquí, por lo que puede que no sea el caso con Castle-Windsor) no es solo la parte de inyección de dependencias lo que lo hace excelente, sino también el marco en sí: gestión de transacciones declarativas, marco de seguridad incorporado, soporte ORM, marco web MVC incorporado, RMI, servicios web, correo electrónico, AOP, etc. Y todo se integra muy bien con el IoC, y el marco realmente hace mucho trabajo para usted en los escenarios más típicos.

Y creo que el cableado automático con anotaciones + soporte IDE (por ejemplo, IntelliJ IDEA para Spring) alivia el problema del archivo de configuración.

No sé si Castle-Windsor es algo más que el contenedor de IoC, pero si lo es, tal vez todavía no esté allí en términos de la riqueza de su funcionalidad como marco.

Answer 3

No creo necesariamente que un contenedor de IoC sea bueno en todos los casos. Pero definitivamente puede ser. Si utiliza la inyección de dependencias o el localizador de servicios para manejar dependencias, ha recorrido un largo camino de todos modos, pero un contenedor IoC puede ayudarlo a hacer las cosas automáticamente, brindarle soporte para escenarios más avanzados, etc.

Intenté definirlo por mí mismo en una publicación de blog hace bastante tiempo:

Un contenedor de inversión de control (IoC) es un componente de fábrica inteligente configurable no invasivo

Dividiendo esta definición en partes, obtenemos

• Fábrica, porque es responsable de crear objetos para usted.

• Inteligente, porque comprende qué dependencias tiene y las crea recursivamente.

• Configurable, porque puede configurar el uso a través de código o archivos de configuración.

• No invasivo, porque los objetos utilizados no necesitan saber sobre el contenedor.

  -

Si lo usa correctamente con la inyección de dependencia o el patrón de localización del servicio, obtendrá algunos beneficios realmente útiles. No necesariamente necesita usar un contenedor externo como Winsor, pero eso le brinda algunos beneficios adicionales.

Puede escribir mucho menos código instanciando nuevos objetos. Y si piensa en jerarquías de objetos más complejas, un contenedor de IoC puede ayudarlo a crear toda la cadena automáticamente. Eso puede ser muy poderoso.

Puede agregar fácilmente versiones simuladas de los objetos durante la prueba sin problemas (si usa DI y / o SL). Por ejemplo, crear un localizador de servicios para usted también resolvería esto.

Cambiar las dependencias que desea inyectar en el constructor no significa necesariamente que necesite refactorizar mucho código.

Obtiene varios beneficios de las dependencias de túnel a través de una fuente: decoradores, interceptores, proxies, así como el manejo del estilo de vida de los objetos. Con un contenedor como Windsor, esto le permite hacer algunas cosas difíciles realmente simples, con muy poco acoplamiento

Puede aprovechar su concepto de instalaciones para una integración sin problemas con, por ejemplo, NHibernate

Answer 4

Le sugiero que escuche el episodio 2 del podcast de Software Engineering Radio. Es todo un episodio de inyección de dependencia. La inyección de dependencia es el uso más conocido de los marcos de inversión de control. También recomendaría escuchar el episodio 362 de DotNetRocks que tiene John Kovacs. Aquí es una transcripción del programa.

Ahora un efecto secundario del COI es una mayor capacidad de prueba. El uso del contenedor IOC como Castle Windsor ayuda a desacoplar las dependencias. Este desacoplamiento mejora la prueba de la unidad.

La mayoría de los marcos del COI también vienen con formas de facilitar la Programación Orientada a Aspectos. Entonces, si está interesado en los marcos de contenedores de COI, puede ayudarlo con eso.