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模式只是一些被高估的模式。为您的应用程序添加更多复杂的图层......

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;
    }
}

Answer 2

IoC容器可以为您做多件事。

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

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

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

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

以及此处陈述的所有正当理由：Why do I need an IoC container as opposed to straightforward DI code?

Answer 3

但谁在乎呢？？这是一个控制器类！我不会重复使用它上课，永远......

这是一个很好的观点，但如果你有嵌套的依赖关系，并且使用不同的生命周期，请考虑代码有多清晰。例如，您可以拥有一些应用程序级单例，需要“按请求”等等。 IoC使您的代码更清晰，易于修改。

在MVC应用程序中使用IoC框架有什么用？

3 个答案: