Что такое использование фреймворка IoC в приложении MVC? [закрытый]

Я пытаюсь понять использование фреймворка IoC, такого как StructureMap, но не могу отделаться от мысли, что эти "шаблоны проектирования" - просто чепуха, делающая код еще более сложным.

Позвольте мне начать с примера, в котором, по моему мнению, МОК несколько полезен.

Я думаю, что IoC может быть полезен при работе с экземплярами классов контроллеров в рамках MVC. В данном случае я имею в виду платформу .NET MVC.

Обычно создание экземпляра класс контроллера обрабатывается платформой. Таким образом, это означает, что вы не можете передать какие-либо параметры конструктору вашего класса контроллера. Вот где может пригодиться структура МОК. Где-то в контейнере IoC вы указываете, какой класс должен быть создан и передан вашим контроллерам constructor при вызове класса контроллера.

Это также удобно, когда вы хотите модульно протестировать контроллер, потому что вы можете имитировать объект, который передается ему.

Но как я уже сказал, я могу отчасти понять, почему люди хотят использовать его для своих классов контроллеров. Но не за пределами этого. С этого момента вы можете просто сделать обычную инъекцию зависимостей.

Но почему бы просто не сделать это так: 

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

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

Теперь вам не нужно использовать какой-либо сторонний фреймворк IoC, что также означает более низкую кривую обучения. Поскольку вам не нужно вдаваться в спецификации этого фреймворка.

Вы все еще можете издеваться над объектом в ваших модульных тестах. Так что никаких проблем нет любой.

Единственное, что вы можете сказать: "но теперь ваш класс тесно связан с SomeObj". Это правда. Но какая разница!? Это класс! Я не собираюсь повторно использовать этот класс, никогда.. Так с какой стати мне беспокоиться об этой тесной связи?.? Я могу издеваться над объектом, который ему передается. Это единственная важная вещь.

Так почему я должен беспокоиться об использовании МОК? Я действительно упускаю главное...? Для меня модель МОК-это просто какая-то переоцененная модель. Добавление еще, сложные слои для вашего приложения...

3 14
c# .net ioc-container design-patterns inversion-of-control

3 ответа:

Вы задаете хороший вопрос, и в вашем примере я бы сказал, что МОК будет / может быть излишним, но просто подумайте о том, что ваш код расширен до следующего, и тогда вы можете начать видеть выгоду от того, что МОК делает все это для вас.

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

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

Есть несколько вещей, которые контейнер IoC может сделать для вас.

Очевидным является обеспечение реализации зависимостей, что имеет смысл в других местах, а не только в контроллерах - если вы решите заменить SomeObj на SomeObj2, Вы можете сделать это только в одном месте, а не в 57 местах .

Еще один-это обработка проблем жизненного цикла, то есть вы можете указать область действия объекта (синглтон, per-thread, per-request, transient...).

Кроме того, контейнер IoC может установите дополнительные зависимости (например, инъекцию свойств), что проще, чем написать следующее: 

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

И все обоснованные причины, изложенные здесь: Почему мне нужен контейнер IoC, а не простой DI-код?

4

Но какая разница!? Это класс! Я не собираюсь повторно использовать это класс, никогда..

Это хороший момент, но подумайте, насколько чище код, если у вас есть вложенные зависимости, с различными жизненными циклами . Например, у вас может быть какой-то синглтон уровня приложения, что-то, что должно быть "по запросу" и так далее. МОК делает только ваш код чище, и его легко модифицировать.

2