Lazy Dependency Dependency

Question

Mam projekt, w którym Ninject jest używany jako kontener IoC. Obawiam się, że wiele klas mają taki rodzaj konstruktorów:

[Inject] 
public HomeController(
    UserManager userManager, RoleManager roleManager, BlahblahManager blahblahManager) { 
    _userManager = userManager; 
    _roleManager = roleManager; 
    _blahblahManager = blahblahManager; 
} 

Co jeśli nie chcę, aby wszystkie instancje tych klas na raz?

Sposób, w jaki wszystkie te klasy są pakowane przez Lazy<T> i przekazywane do konstruktora, nie jest dokładnie tym, czego potrzebuję. Instancje T nie zostały jeszcze utworzone, ale instancje Lazy<T> są już przechowywane w pamięci.

Mój kolega sugeruje, żebym używał wzoru Fabryki do kontrolowania wszystkich wystąpień, ale nie jestem pewien, czy IoC ma tak świetny błąd w projektowaniu.

Czy istnieje obejście tego problemu, czy IoC ma tak dużą wadę w swoim projekcie? Może powinienem użyć innego pojemnika IoC?

Wszelkie sugestie?

Answer 1

Wydaje mi się, że robisz premature optimization: nie rób tego.

Konstruktorzy twoich usług powinni wykonać nothing more, niż przechowywać zależności, które pobiera w polach prywatnych. W takim przypadku stworzenie takiego obiektu jest naprawdę niewielkie. Nie zapominaj, że tworzenie obiektów w .NET jest naprawdę szybkie. W większości przypadków, z perspektywy wydajności, po prostu nie ma znaczenia, czy te zależności zostaną wstrzyknięte, czy nie. Szczególnie w porównaniu do ilości obiektów, reszta aplikacji (i frameworki, których używasz) wypluwają. Rzeczywiste koszty powstają, gdy zaczynasz korzystać z usług internetowych, baz danych lub systemu plików (lub ogólnie z I/O), ponieważ powodują one znacznie większe opóźnienie.

Jeśli tworzenie jest naprawdę drogie, zwykle ukrywaj kreację za Virtual Proxy zamiast wstrzykiwać Lazy<T> w każdym kliencie, ponieważ pozwala to zwykłemu kodowi aplikacji pozostać obojętnym na fakt, że istnieje mechanizm opóźniający tworzenie (zarówno kod aplikacji, jak i kod testowy stają się coraz bardziej złożone, gdy to robisz).

Rozdział 6 z Dependency Injection in .NET, second edition zawiera bardziej szczegółową dyskusję na temat leniwych i wirtualnych serwerów proxy.

Jednakże Lazy<T> zużywa tylko 20 bajtów pamięci (a na jego kolejny 24 bytes owinięty Func<T>, zakładając, że proces 32-bitowy), i utworzenie przykład Lazy<T> jest prawie bezpłatne. Nie musisz się tym martwić, z wyjątkiem sytuacji, gdy jesteś w środowisku z bardzo ograniczonymi ograniczeniami pamięci.

Jeśli zużycie pamięci stanowi problem, spróbuj zarejestrować usługi o czasie życia dłuższym niż przejściowy. Możesz to zrobić na żądanie, na żądanie internetowe lub na singleton. Powiedziałbym nawet, że gdy znajdujesz się w środowisku, w którym tworzenie nowych obiektów jest problemem, prawdopodobnie powinieneś używać tylko usług singleton (ale jest mało prawdopodobne, że pracujesz nad takim środowiskiem, ponieważ budujesz aplikację internetową) .

Należy zauważyć, że Ninject jest jedną z wolniejszych bibliotek DI dla .NET. Jeśli to Cię niepokoi, switch to a faster container. Niektóre pojemniki mają wydajność zbliżoną do ręcznego tworzenia wykresów obiektów. ale na wszelkie sposoby, zrób to, wielu programistów przełącza biblioteki DI z niewłaściwych powodów.

Należy zauważyć, że używanie Lazy<T> jako zależności to leaky abstraction (naruszenie Dependency Inversion Principle). Przeczytaj this answer, aby uzyskać więcej informacji.

Answer 2

New

Steven ma rację mówiąc, że to wygląda jak przedwczesny optymalizacji. Konstrukcja tych obiektów jest bardzo szybka i zwykle nie jest wąskim gardłem.

Jednak używanie Lazy do wyrażania zależności, której nie potrzebujesz od razu, jest typowym schematem w ramach Dependency Injection. Actofac to jeden taki kontener, który ma wbudowaną obsługę various wrapping types. Jestem pewien, że istnieje również rozszerzenie dla Ninject, może spojrzeć na to, Ninject Lazy.