Ninject vs Unity para DI [cerrado]

104

Estamos utilizando ASP.net MVC.

¿Cuál de estos es el mejor marco de DI Ninject o Unity y por qué?

asp.net-mvc ninject unity-container Miral
fuente
94
NInject es mejor porque puede comprar imanes de marca geniales en su sitio web.
Ivan G.
5
Versión actualizada de esta pregunta (muy similar de todos modos) que algunas personas pueden encontrar útil: stackoverflow.com/questions/4581791/…
Jason Down

Respuestas:

46

La última vez que miré a cualquiera de ellos encontré a Ninject un poco mejor. Pero ambos tienen sus inconvenientes.

Ninject tiene un mejor esquema de configuración fluida. Unity parece depender principalmente de la configuración XML. El principal inconveniente de Ninject es que requiere que hagas referencia a Ninject.Core en todas partes de tu código para agregar atributos [Inject].

Si puedo preguntar, ¿por qué limita sus opciones a estos dos? Creo que Castle.Windsor, Autofac y StructureMap son al menos tan buenos o mejores.

Mendelt
fuente
47
Solo necesita usar el atributo Inject si hay más de un constructor y necesita decirle a Ninject qué constructor usar. De forma predeterminada, utiliza el constructor con la mayor cantidad de parámetros.
Jeffrey Cameron
11
Mientras tanto, también hay una extensión oficial de Ninject.Web.Mvc. Cambia su MvcApplication para derivar de NinjectHttpApplication, gira el Kernel y llama a RegisterAllControllersIn (Assembly.GetExecutingAssembly ()) para que se encargue de todos los controladores en el ensamblado dado. Magia.
Michael Stum
18
Esta respuesta ahora es bastante irrelevante con respecto a Ninject 2. Si bien la queja era legítima para Ninject 1, Ninject 2 permite trabajar sin ensuciar las clases con atributos. ninject2 funcionará de forma transparente sin la necesidad de modificar sus clases.
chillitom
3
Lo mismo para la unidad, ya que parece ser completamente configurable a través del código en este punto (v3.0.1304.1)
Eric
46

Sé que esta es una pregunta antigua, pero aquí están mis pensamientos:

Personalmente, me gusta Ninject. Me gustan las interfaces fluidas y evitar XML. Generalmente me gusta XML, pero no para este tipo de cosas de configuración. Especialmente cuando se trata de refactorización, las interfaces fluidas facilitan la corrección.

Echo de menos ObjectFactory de StructureMap, pero hay soluciones fáciles para agregar eso a Ninject.

Como señala Jeffery, no es necesario utilizar el atributo [Inject] cuando solo tiene un constructor.

Descubrí que prefiero las interfaces fluidas no solo porque evitan XML, sino porque causan errores en el tiempo de compilación cuando cambio algo que las afecta. La configuración XML no lo hace y cuanto menos tengo que recordar cambiar, mejor estoy.

roberocidad
fuente
10

Ninject detecta dependencias circulares si usa Injection Constructors en lugar de Unity que, independientemente de la técnica de inyección, simplemente arroja una StackOverflowException que es extremadamente difícil de depurar.

IMLiviu
fuente
9

Estoy de acuerdo con Mendelt, no existe un marco de DI "mejor". Depende de la situación y todos tienen pros y contras. Creo que David Hayden dijo en DotNet Rocks que Unity es la opción preferida si usa el resto de EntLib y está familiarizado con eso. Yo personalmente uso Unity porque a mi cliente le gusta el hecho de que dice Microsoft Enterprise Library (Unity) en las DLL, si entiendes lo que estoy diciendo.

Utilizo tanto la configuración xml para configurar las interfaces como sus implementaciones concretas, pero luego uso atributos en el código al inyectar, como:

<type type="ILogger" mapTo="EntLibLogger">
   <lifetime type="singleton"/>
</type>

y en código:

[InjectionConstructor]
public Repository([Dependency] ILogger logger)

Personalmente, creo que eso deja más claro lo que sucede, pero, por supuesto, se podría argumentar que tendrá referencias a la unidad en toda su aplicación. Tu decides.

Johan Leino
fuente