Ninject vs Unity for DI [zamknięte]

Używamy ASP.net MVC.

Który z nich jest najlepszym frameworkiem DI Ninject lub Unity i dlaczego?

Ostatnim razem, gdy spojrzałem na którykolwiek z nich, znalazłem Ninject trochę lepiej. Ale obie mają swoje wady.

Ninject ma lepszy schemat płynnej konfiguracji. Wydaje się, że Unity polega głównie na konfiguracji XML. Główną wadą Ninject jest to, że wymaga on odwoływania się do Ninject.Core w każdym miejscu w kodzie, aby dodać atrybuty [Inject].

Jeśli mogę zapytać, dlaczego ograniczasz swoje wybory do tych dwóch? Myślę, że Castle.Windsor, Autofac i StructureMap są co najmniej tak samo dobre lub lepsze.

Wiem, że to stare pytanie, ale oto moje myśli:

Osobiście lubię Ninject. Lubię płynne interfejsy i unikanie XML. Generalnie lubię XML, ale nie do tego rodzaju konfiguracji. Zwłaszcza w przypadku refaktoryzacji płynne interfejsy ułatwiają poprawianie.

Brakuje mi ObjectFactory StructureMap, ale są łatwe obejścia, aby dodać to do Ninject.

Jak zauważa Jeffery, nie musisz używać atrybutu [Inject], gdy masz tylko jednego konstruktora.

Odkryłem, że wolę płynne interfejsy nie tylko dlatego, że unikają XML, ale dlatego, że powodują błędy czasu kompilacji, gdy zmieniam coś, co ich dotyczyło. Konfiguracja XML nie działa, a im mniej muszę pamiętać, aby zmienić, tym lepiej mam.

Ninject wykrywa zależności cykliczne, jeśli używasz konstruktorów iniekcji w przeciwieństwie do Unity, które niezależnie od techniki iniekcji po prostu zgłasza StackOverflowException, który jest niezwykle trudny do debugowania.

Zgadzam się z Mendeltem, nie ma „najlepszego” schematu DI. Zależy to tylko od sytuacji i wszyscy mają wady i zalety. myślę, że David Hayden powiedział w DotNet Rocks, że Unity jest preferowanym wyborem, jeśli używasz reszty EntLib i znasz to. Osobiście używam Unity, ponieważ mojemu klientowi podoba się fakt, że mówi on o Microsoft Enterprise Library (Unity) w bibliotekach DLL, jeśli rozumiesz to, co mówię.

Używam zarówno konfiguracji XML do konfigurowania interfejsów, jak i ich konkretnych implementacji, ale potem używam atrybutów w kodzie podczas wstrzykiwania, takich jak:

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

iw kodzie:

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

Osobiście uważam, że to wyjaśnia, co się dzieje, ale oczywiście można argumentować, że w całej aplikacji będą występowały odniesienia do jedności. To zależy od Ciebie.

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

Jedność jest szybsza, ale nie najlepsza