14

我试图理解使用像 StructureMap 这样的 IoC 框架，但我不禁认为这些“设计模式”只是无稽之谈，使代码变得更加复杂。

让我从一个我认为 IoC 有点用处的例子开始。

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

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

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

但就像我说的，我可以理解为什么人们想将它用于他们的控制器类。但不在此之外。从那里你可以简单地做正常的依赖注入。

但为什么不简单地这样做：

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

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

现在您不必使用任何第 3 方 IoC 框架，这也意味着更低的学习曲线。因为您也不必了解该框架的规范。

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

你唯一能说的是，“但是现在你的类是紧密耦合到的SomeObj”。这是真实的。但谁在乎！？这是一个控制器类！我永远不会重用那个类..那么我到底为什么要担心这种紧密耦合..？我可以模拟传递给它的对象。这是唯一重要的事情。

那么我为什么要费心使用 IoC 呢？我真的错过了重点吗...？对我来说，IoC 模式只是一些被高估的模式。向您的应用程序添加更多、复杂的层...

4

3 回答 3

8

您提出了一个很好的问题，在您的示例中，我会说 IoC 会/可能是矫枉过正，但只需考虑将您的代码扩展到以下内容，然后您可能会开始看到让 IoC 为您完成所有这些工作的好处。

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

    publiv SomeController(SomeObj obj)
    {
        this.obj = obj;
    }
}
于 2013-03-18T16:04:14.667 回答
4

IoC 容器可以为您做很多事情。

显而易见的是提供依赖项的实现，这在其他地方很有意义，而不仅仅是在控制器中 - 如果您决定替换SomeObj为SomeObj2，您可以只在一个地方完成，而不是 57 个地方。

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

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

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

以及这里陈述的所有充分理由：为什么我需要一个 IoC 容器而不是简单的 DI 代码？

于 2013-03-18T16:03:41.953 回答
2

但谁在乎！？这是一个控制器类！我不会重用那个类，永远..

这是一个很好的观点，但是如果您有嵌套的依赖项，并且具有不同的生命周期，请考虑代码的简洁程度。例如，您可以有一些应用程序级别的单例，需要“按请求”的东西等等。IoC 使您的代码更简洁，并且易于修改。

于 2013-03-18T16:05:20.397 回答