Ninject vs Unity para DI

Question

Estamos utilizando ASP.net MVC.

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

Answer 1

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

Ninject tiene un mejor esquema de configuración de fluencia. La unidad parece depender principalmente de la configuración XML. La principal desventaja de Ninject es que requiere que haga referencia a Ninject.Core en todas partes de su código para agregar atributos [Inject].

Si me permite la pregunta, ¿por qué estás limitando sus opciones a estos dos? Creo que Castle.Windsor, Autofac y StructureMap son al menos tan buenos o mejores.

Answer 2

Estoy de acuerdo con Mendelt, no existe un marco DI "mejor". Simplemente 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 digo.

Puedo utilizar tanto la configuración XML para configurar las interfaces y sus implementaciones concretas pero entonces utilizar atributos en el código cuando se inyecta, como:

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

y en el código:

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

Personalmente Creo que eso aclara lo que sucede, pero, por supuesto, uno podría argumentar que tendrá referencias a la unidad en toda su aplicación. Tu decides.

Answer 3

Sé que esto es una vieja pregunta, 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 lo hacen más fácil de corregir.

Extraño ObjectFactory de StructureMap, pero hay soluciones fáciles de agregar para Ninject.

Como Jeffery señala que no tiene que usar el atributo [Inyectar] cuando solo tiene un constructor.

Descubrí que prefiero las interfaces fluidas no solo porque evitan XML, sino también porque causan errores de tiempo de compilación cuando cambio algo que los afectó. La configuración XML no y menos tengo que recordar para cambiar lo mejor que estoy.

Answer 4

http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison

La unidad es más rápido, pero no es la mejor

Answer 5

Ninject detecta dependencias circulares si utiliza constructores de inyección en lugar de la unidad que, independientemente de la técnica de inyección simplemente lanza una StackOverflowException que es extremadamente difícil de depurar.