在MVC应用中，什么是IoC框架的作用？

Question

我正在尝试理解像StructureMap这样的IoC框架的用途，但我不禁想到这些“设计模式”只是无意义的，使代码更加复杂。

让我以一个例子开始，我认为在这种情况下使用IoC有点有用。

我认为在处理MVC框架中控制器类的实例化时，IoC可能会有用。在这种情况下，我正在考虑.NET MVC框架。

通常，控制器类的实例化由框架处理。这意味着您不能真正传递任何参数到控制器类的构造函数中。 这就是IoC框架有用的地方。在IoC容器的某个地方，您指定应该实例化哪个类并将其传递给控制器的constructor当调用控制器类时。

当您想要对控制器进行单元测试时，这也很方便，因为您可以模拟传递给它的对象。

但是，就像我说的那样，我有点能理解人们为什么想要在控制器类中使用它。但不能超出那个范围。从那里开始，您可以简单地进行普通的依赖注入。

但为什么不像这样做呢：

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

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

现在你不必使用任何第三方IoC框架，这也意味着学习曲线更低。因为你不必去了解那个框架的规格。

你仍然可以在单元测试中模拟对象。所以也没有问题。

唯一需要说的是，“但现在你的类与SomeObj紧密耦合”。这是正确的。但谁在乎呢！它是一个控制器类！我永远不会重用那个类.. 那么我为什么要担心这种紧密耦合呢..？我可以模拟传递给它的对象。那才是最重要的。

所以我为什么要费事使用IoC呢？难道我真的错过了什么关键点吗...? 对我来说，IoC模式只是一种被高估的模式。给你的应用程序添加更多复杂的层...

- w00

---

@HenkHolterman 并不是说当有人提出了好的论据来说明我的方法是错误的，并且在什么情况下是错误的，我就一定会反驳。我并不打算和任何人争论。只是想寻求关于这个问题的建议。 - w00

可能是为什么我需要IoC容器而不是直接使用DI代码？的重复问题。 - Zdeslav Vojkovic

Answer 1

你问了一个好问题，在你的例子中，我会说IoC可能有点“杀鸡焉用牛刀”，但是如果你考虑到代码的扩展性，那么你可能会看到让IoC来完成所有这些工作的益处。

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

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

- Paul Hadfield

Answer 2

IoC容器可以为您提供多种功能。

显而易见的是，它能够为依赖项提供实现，在控制器以外的其他地方也是有意义的-如果您决定将 SomeObj 替换为 SomeObj2 ，则只需在一个地方进行更改，而不是57个地方。

另一个功能是处理生命周期问题，即您可以指定对象的范围（单例、每线程、每请求、瞬态等）。

此外，IoC容器可以设置可选依赖项（即属性注入），这比编写以下内容更容易：

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

以下是所有好的理由：为什么我需要IoC容器而不是直接使用DI代码？

- Zdeslav Vojkovic

Answer 3

但是谁在乎呢？这只是一个控制器类！我永远不会重复使用那个类。

这是一个好观点，但考虑一下如果您有嵌套依赖项，具有不同的生命周期，代码会变得多么干净。例如，您可以拥有一些应用程序级别的单例，需要“每个请求”等等。IoC使您的代码更加清晰，易于修改。

- Felice Pollano