W których ramach wstrzykiwania zależności .NET warto się przyjrzeć? [Zamknięte]

W których ramach C # / .NET Dependency Injection warto się przyjrzeć? Co możesz powiedzieć o ich złożoności i szybkości.

edycja (nie autor): Pełna lista ram IoC dostępna jest na stronie https://github.com/quozd/awesome-dotnet/blob/master/README.md#ioc :

• Castle Windsor - Castle Windsor to najlepszy w swojej klasie, dojrzały kontener Inversion of Control dostępny dla platform .NET i Silverlight
• Unity - Lekki rozszerzalny pojemnik do wstrzykiwania zależności z obsługą konstruktora, właściwości i wstrzykiwania wywołania metody
• Autofac - uzależniający kontener IoC .NET
• DryIoc - Prosty, szybki, w pełni wyposażony pojemnik IoC.
• Ninject - Ninja wtryskiwaczy zależności .NET
• StructureMap - oryginalny kontener IoC / DI dla .Net
• Spring.Net - Spring.NET to platforma aplikacji typu open source, która ułatwia budowanie korporacyjnych aplikacji .NET
• LightInject - ultralekki pojemnik IoC
• Simple Injector - Simple Injector to łatwa w użyciu biblioteka Dependency Injection (DI) dla .NET 4+, która obsługuje Silverlight 4+, Windows Phone 8, Windows 8, w tym aplikacje Universal i Mono.
• Microsoft.Extensions.DependencyInjection - domyślny kontener IoC dla aplikacji ASP.NET Core.
• Scrutor - Rozszerzenia skanowania zestawu dla Microsoft.Extensions.DependencyInjection.
• VS MEF - implementacja Managed Extensibility Framework (MEF) używana przez Visual Studio.
• TinyIoC - łatwy w użyciu, bezproblemowy, Inversion of Control Container dla małych projektów, bibliotek i początkujących.

Oryginalna odpowiedź następuje.

Przypuszczam, że mogłem być nieco wybredny, ale ważne jest, aby pamiętać, że DI (Dependency Injection) jest wzorcem programowania i jest ułatwiony przez, ale nie wymaga, szkielet IoC (Inversion of Control). Ramy IoC po prostu znacznie ułatwiają DI i zapewniają szereg innych korzyści wykraczających poza DI.

Biorąc to pod uwagę, jestem pewien, że o to pytasz. Informacje o ramach IoC; Kiedyś często korzystałem z Spring.Net i CastleWindsor , ale prawdziwym bólem z tyłu była cała ta nieznośna konfiguracja XML, którą musiałeś napisać! Teraz wszystkie poruszają się w ten sposób, więc używam StructureMap od około roku, a ponieważ przeszedł do płynnej konfiguracji przy użyciu silnie wpisanych generycznych i rejestru, moja bariera bólu w korzystaniu z IoC spadła do poniżej zera! Absolutnie nie rozumiem, że teraz moja konfiguracja IoC jest sprawdzana w czasie kompilacji (w przeważającej części) i czerpię radość z StructureMap i jego szybkości. Nie powiem, że inni spóźnili się w czasie wykonywania, ale trudniej mi było je skonfigurować, a frustracja często wygrywała dzień.

Aktualizacja

Używam Ninject do mojego najnowszego projektu i korzystanie z niego było absolutną przyjemnością. Słowa zawiodły mnie tutaj trochę, ale (jak mówimy w Wielkiej Brytanii) ten schemat to „Psy”. Gorąco poleciłbym go do wszelkich projektów zielonych pól, w których chcesz szybko rozpocząć działalność. Dostałem wszystko, czego potrzebowałem, od fantastycznego zestawu screenów Ninject autorstwa Justina Etheredge. Nie widzę, aby retro-dopasowanie Ninject do istniejącego kodu w ogóle stanowiło problem, ale z mojego doświadczenia można powiedzieć to samo o StructureMap . Będzie to trudny wybór między tymi dwoma, ale wolałbym raczej rywalizację niż stagnację i jest tam sporo zdrowej rywalizacji.

Inne screencasty IoC można również znaleźć tutaj na Dimecastach .

To zależy od tego, czego szukasz, ponieważ każdy ma swoje zalety i wady.

1. Spring.NETjest najbardziej dojrzały, ponieważ pochodzi ze Wiosny ze świata Java. Spring ma bardzo bogaty zestaw bibliotek frameworkowych, które rozszerzają go o obsługę sieci, Windows itp.
2. Castle Windsorjest jednym z najczęściej używanych na platformie .NET i ma największy ekosystem, jest wysoce konfigurowalny / rozszerzalny, ma niestandardowe zarządzanie dożywotnie, wsparcie AOP, ma nieodłączne wsparcie NHibernate i jest wszechstronnym kontenerem. Windsor jest częścią całego stosu, który obejmuje Monorail, Active Record itp. Sam NHibernate buduje na Windsor.
3. Structure Map ma bardzo bogatą i drobnoziarnistą konfigurację poprzez wewnętrzny DSL.
4. Autofacto kontener IoC nowej ery z nieodłącznym wsparciem programowania funkcjonalnego. Podejmuje także inne podejście do zarządzania czasem życia niż inne. Autofac jest wciąż bardzo nowy, ale przesuwa poprzeczkę, co jest możliwe dzięki IoC.
5. Ninject Słyszałem, że jest więcej nagich kości, a mniej oznacza więcej podejścia (słyszałem, że nie doświadczyłem).
6. Największy dyskryminator Unityto: pochodzi od i jest obsługiwany przez Microsoft (p & p). Unity ma bardzo dobrą wydajność i świetną dokumentację. Jest również wysoce konfigurowalny. Nie ma wszystkich dzwonków i gwizdów powiedzmy na mapie zamku / struktury.

Podsumowując, tak naprawdę zależy to od tego, co jest dla Ciebie ważne. Zgodziłbym się z innymi w sprawie pójścia, oceny i sprawdzenia, który z nich pasuje. Fajną rzeczą jest to, że masz ładny wybór pączków, a nie tylko galaretkę.

Autofac. https://github.com/autofac/Autofac To jest naprawdę szybkie i całkiem dobre. Oto link z porównaniami (dokonany po tym, jak Ninject naprawił problem wycieku pamięci).

http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html

Ninject jest świetny. Wydaje się to bardzo szybkie, ale nie dokonałem żadnych porównań. Wiem, że Nate, autor, dokonał porównań między Ninject i innymi frameworkami DI i szuka innych sposobów na poprawę szybkości Ninject.

Słyszałem, że wiele osób, które szanuję, mówią dobre rzeczy o StructureMap i CastleWindsor. Moim zdaniem są to wielkie trzy, na które można teraz spojrzeć.

Używam Simple Injector :

Simple Injector to łatwa, elastyczna i szybka biblioteka wstrzykiwania zależności, która wykorzystuje najlepsze praktyki, aby poprowadzić twoje rozwiązania w kierunku sukcesu.

Jestem wielkim fanem Castle. Uwielbiam udogodnienia, które zapewnia poza IoC Container. To naprawdę upraszcza korzystanie z NHibernate, logowania, AOP, itp. Używam również Binsor do konfiguracji z Boo i naprawdę zakochałem się w Boo jako języku z tego powodu.

Mogę polecić Ninject. Jest niezwykle szybki i łatwy w użyciu, ale tylko wtedy, gdy nie potrzebujesz konfiguracji XML, w przeciwnym razie powinieneś użyć Windsor.

Spędziłem większą część dnia walcząc bez powodzenia, aby uruchomić najprostszy przykład Spring.NET. Nigdy nie mogłem dowiedzieć się, jak go znaleźć, aby znaleźć mój zestaw z pliku XML. Z drugiej strony w około 2 godziny udało mi się uruchomić Ninject, w tym przetestować integrację z NUnit i MSTest.

W przeszłości korzystałem z Spring.NET i odniosłem z nim wielki sukces. Nigdy nie zauważyłem żadnych znacznych kosztów ogólnych, chociaż projekt, w którym go użyliśmy, był sam w sobie dość ciężki. Przygotowanie dokumentacji zajęło trochę czasu .

Wspaniałą rzeczą w C # jest to, że podąża ścieżką przebytą przez lata deweloperów Java przed nim. Tak więc, moja rada, mówiąc ogólnie, gdy szukam narzędzi tego rodzaju, jest poszukiwanie solidnej odpowiedzi w Javie i sprawdzenie, czy istnieje jeszcze adaptacja .NET.

Więc jeśli chodzi o DI (i jest tak wiele opcji, to naprawdę kwestia gustu) to Spring.NET . Ponadto zawsze mądrze jest badać osoby odpowiedzialne za projekty. Nie mam problemu z sugerowaniem produktów SourceGear do kontroli źródła (poza ich używaniem), ponieważ mam szacunek dla Erica Sink. Widziałem, jak Mark Pollack mówił i co mogę powiedzieć, facet po prostu to rozumie.

Ostatecznie istnieje wiele frameworków DI, a najlepszym rozwiązaniem jest wykonanie kilku przykładowych projektów z kilkoma z nich i dokonanie świadomego wyboru.

Powodzenia!

Myślę, że dobrym miejscem na początek jest Ninject, jest nowy i wziął pod uwagę wiele dostrajania i jest naprawdę szybki. Nate, programista, naprawdę ma świetną stronę i świetne wsparcie.

Spring.Net jest dość solidny, ale dokumentacja zajęła trochę czasu. Autofac jest dobry i chociaż .Net 2.0 jest obsługiwany, potrzebujesz VS 2008, aby go skompilować, lub użyj wiersza poleceń do zbudowania aplikacji.