Nombre un marco de inyección de dependencia simple

Me gustaría intentar usar un marco DI/IoC por primera vez en un proyecto pequeño pero en crecimiento, y no quiero perturbar demasiado el proyecto al introducir dependencias voluminosas. El proyecto en sí está destinado en parte a ser utilizado como una biblioteca en otros proyectos, y no quiero molestar a los usuarios con la gestión de dependencias adicionales. También es una cuestión de gusto: creo que el tamaño de un componente debe ser proporcional a la cantidad de servicios que realmente necesito. Odio incorporar un componente voluminoso con dependencias propias, solo para usar una pequeña parte de él.Nombre un marco de inyección de dependencia simple

Por lo tanto, para .NET, hay un pequeño marco DI/IoC que se compila en una única DLL sin dependencias que no sean bibliotecas estándar, que (si es necesario) podría incrustarse directamente en el ensamblado que la utiliza, y enfatiza el cableado basado en código/fluido (en lugar de XML)? No debe requerir .NET framework 4.0.

Fuente

2010-08-10 Qwertie

No necesita una biblioteca en absoluto si solo desea la Inversión de control. Solo inserte sus dependencias a través del constructor de su clase. –

Ahora mismo eso es lo que estoy haciendo. Sin embargo, el cableado de las cosas está empezando a ser un poco engorroso y sé que empeorará a medida que el proyecto crezca. (Es un proyecto de compilación compuesto por numerosos componentes y debería ser posible intercambiar componentes por otros ...) – Qwertie

Estoy de acuerdo con Robert. Al inyectar dependencias en el código, también obtiene el beneficio del compilador. Normalmente cableo mi aplicación en el método Main(). –

Me siento muy parecido a como lo hace con los marcos IOC. Uso el COI todo el tiempo, simplemente no veo la necesidad de un Marco mucho.

Una vez dicho esto, el que yo usaría si tuviera que elegir uno sería AutoFac

Es muy sencillo, fácil de entender, y se siente ligero.

Fuente

2010-08-10 17:52:30 CubanX

http://nblumhardt.com/2010/04/introducing-autofac-2-1-rtw/ - dice "Autofac utiliza el soporte subyacente en .NET 4.0" – Qwertie

Derecha, AutoFac 2.1 sí. Pero las versiones anteriores a eso (1.4) no necesitan 4.0. Si está implementando una aplicación 4.0, entonces el hecho de que utilice las cosas subyacentes de .Net es algo bueno :) – CubanX

Estoy restringido a VS 2008 y, además, no quiero exigirles a los usuarios que actualicen su .NET Framwork. Parece que hay una versión .NET 3.5 de AutoFac 2.2 pero viene con 5 DLL y un archivo XML más grande que los 5 DLL combinados. Me pregunto cuánto de eso se requiere. – Qwertie

Eche un vistazo a Ninject.

Fuente

2010-08-10 17:50:56

La descarga de .NET Framework 3.5 en http://ninject.org/download contiene 6 archivos DLL que superan la mitad de un meg, más pesado de lo que esperaba. – Qwertie

Todo lo que hace referencia en su proyecto es el conjunto único Ninject.dll que cumple con sus criterios de peso ligero. Existe un conjunto de ensambles Extensions y Web.Mvc que es aditivo a la funcionalidad base de NInject si lo necesita. –

¿Son esos ensamblados opcionales o Ninject.dll los requiere? ¿Se requiere el archivo XML? – Qwertie

También sugeriría, además de NInject, que mire Microsoft DI Framework, Unity.

Fuente

2010-08-10 17:59:48

Probar StructureMap.

El núcleo StructureMap.dll es bastante pequeño.

Fuente

2010-08-10 18:08:32

Trabajo con un sistema bastante grande y hemos inyectado todo manualmente. Hacemos uso del patrón abstracto de fábrica para poner en orden la mayor parte de la inyección/cableado y funcionó bien.

DI Frameworks son abundantes. Antes de asumir una dependencia externa adicional, tómese un tiempo para considerar si la aplicación de un patrón diferente/nuevo resolvería sus problemas.

edición: (posiblemente sesgados/injustos) Razones por las que no han utilizado un marco DI:

Si utiliza un marco DI, usted tiene que enviar el marco DI con su software. Esto puede ser un obstáculo para algunos, y otros podrían tener que discutir los méritos de la dependencia adicional.
Todavía tiene que construir constructores para tomar dependencias
Y aún tiene que contar (o al menos dar pistas) en el marco DI qué usar. La única diferencia importante es que uses la fábrica de DI en lugar de la tuya.

En cuanto a la construcción de esa fábrica, la mayoría de las herramientas de refactorización pueden hacer el 90% del trabajo con muy pocas teclas.

Fuente

2010-08-10 18:10:14

¿Has usado realmente un marco DI? Si es así, ¿descubrió que era más problemático de lo que valía? – Qwertie

No veo cómo la inyección manual en un sistema grande es ** menos trabajo ** que hacerlo automáticamente usando un marco DI. –

La respuesta fue un poco larga para un comentario, edité mi respuesta. –

Cualquier marco que introduzca eventualmente se convertirá en una dependencia de su aplicación. Además, las personas tienen diversas definiciones de lo que es el peso ligero. Eche un vistazo a Unity, o StructureMap o Castle Windsor, ya que tienden a ser más populares. Scott Hanselman tiene una lista completa, here. Elige tu opción.

Fuente

2010-08-10 18:51:13 Roman

+1 para la lista. Técnicamente, si inserto el contenedor IoC en uno de mis archivos DLL y cambio el espacio de nombres, no se verá como una dependencia desde el exterior, además tendría la opción de eliminar todo lo que no uso. Dado cómo explican su diseño, estoy pensando (Windsor) MicroKernel es susceptible a ese enfoque ... – Qwertie

@Qwertie en la parte inferior de la publicación de Hanselman referenciada es un enlace a dos contenedores de IoC en 15 líneas de códigos. Su objetivo es ser extremadamente liviano cuando no se necesita un "marco". Quizás vale la pena investigarlo. –

Existen examples on the web sobre cómo escribir su propio contenedor, aunque son muy básicas y carecerían de características proporcionadas por un marco más robusto.

Fuente

2010-08-20 16:03:07 Matt

Nombre un marco de inyección de dependencia simple

Respuesta

Cuestiones relacionadas