Jakie jest zastosowanie ram IoC w aplikacji MVC?

Question

Próbuję zrozumieć użycie ram IoC takich jak StructureMap, ale nie mogę przestać myśleć, że te "wzorce projektowe" są po prostu nonsensem, czyniąc kod bardziej złożonym.

Pozwól mi zacząć od przykładu, w którym myślę, że IoC jest nieco przydatny.

Myślę, że IoC może być przydatny, gdy mamy do czynienia z tworzeniem klas kontrolerów w środowisku MVC. W tym przypadku myślę o środowisku .NET MVC.

Zwykle instancja klasy kontrolera jest obsługiwana przez framework. Oznacza to, że naprawdę nie można przekazać żadnych parametrów do konstruktora klasy kontrolera. Tutaj może się przydać struktura IoC. Gdzieś w kontenerze IoC określasz, która klasa powinna być tworzona i przekazywana do kontrolerów constructor, gdy klasa kontrolera jest wywoływana.

Jest to również przydatne, gdy chcesz przetestować kontroler, ponieważ możesz kpić z obiektu, który jest do niego przekazywany.

Ale jak powiedziałem, mogę nieco zrozumieć, dlaczego ludzie chcą używać go do swoich klas kontrolerów. Ale nie poza tym. Stamtąd możesz po prostu zrobić normalny Dependency Injection.

Ale dlaczego nie po prostu zrobić to tak:

public class SomeController 
{ 
    public SomeController() : this(new SomeObj()) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 

Teraz nie trzeba używać żadnych 3rd party IoC ram co oznacza również niższą krzywą uczenia się. Ponieważ nie musisz także wchodzić w specyfikacje tego schematu.

Nadal można kpić z obiektu podczas testów jednostkowych. Więc też nie ma problemu.

Jedyne, co możesz powiedzieć, to "ale teraz twoja klasa to ściśle sprzężona z SomeObj". To prawda. Ale kogo to obchodzi!? To klasa kontrolerów! Nie wykorzystam tej klasy, nigdy ... Dlaczego więc, na litość, powinienem się martwić tym mocnym sprzężeniem ...? Mogę wyśmiać obiekt, który jest do niego przekazywany. To jedyna ważna rzecz.

Dlaczego więc powinienem zawracać sobie głowę używaniem IoC? Czy NAPRAWDĘ brakuje mi punktu ...? Dla mnie wzór IoC jest po prostu przereklamowanym wzorem. Dodawanie bardziej złożonych warstw do aplikacji ...

Answer 1

zadać dobre pytanie w swoim przykładzie chciałbym powiedzieć, że IoC będzie/może być przesada, ale po prostu rozważ swój kod rozszerzony do następujących, a następnie możesz zacząć korzystać z zalet IoC zrobić to wszystko dla ciebie.

public class SomeController 
{ 
    public SomeController() : this(new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo()))) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 

Answer 2

Istnieje wiele rzeczy, które kontener IoC może dla Ciebie zrobić.

Oczywistym jeden jest zapewnienie realizacji do zależności, która ma sens w innych miejscach, nie tylko w sterownikach - Jeśli zdecydujesz się zastąpić SomeObj z SomeObj2, można to zrobić tylko w jednym miejscu, zamiast w 57 miejscach.

Inną jest obsługa problemów związanych z cyklem życia, tj. Można określić zakres obiektu (pojedyncza, na wątek, na żądanie, przejściowa ...).

Dodatkowo kontener IoC może ustawić opcjonalne zależności (np.wtrysk nieruchomości), co jest łatwiejsze niż pisanie to:

var svc = new Service(new MyRepository()) 
svc.Logger = logger; 
svc.XY = xy 

i wszystkie powody podane tutaj: Why do I need an IoC container as opposed to straightforward DI code?

Answer 3

Ale kogo to obchodzi !? To klasa kontrolerów! Nie jadę do ponownego użycia, które klasy, nigdy ..

Jest to dobry punkt, ale zastanowić się, jak odkurzacz jest kod jeśli zagnieżdżone zależności, z różnych cyklach. Na przykład możesz mieć jakiś singleton na poziomie aplikacji, coś, co musi być "na żądanie" i tak dalej. IoC sprawia, że ​​twój kod jest czystszy i łatwy do modyfikacji.