Какая польза от структуры IoC в приложении MVC?

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

Позвольте мне начать с примера, где я думаю, что IoC несколько полезен.

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

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

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

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

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

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

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

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

Вы все еще можете высмеивать объект в своих тестах единиц. Поэтому проблем нет.

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

Итак, почему я должен использовать IoC? У меня ДЕЙСТВИТЕЛЬНО отсутствует пункт...? Для меня шаблон IoC - это просто переоцененный шаблон. Добавление дополнительных, сложных слоев в ваше приложение...

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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