ioc-container - 为什么要使用 IoC 框架

Question

我一直在阅读有关控制反转框架的内容，而我只是在玩弄这个问题:“我到底为什么需要一个框架来做到这一点？”

不要误解我的问题...该模式是我们程序员经常使用的，但是...一个功能齐全的框架可以做到这一点？

我一定遗漏了一些东西，这就是我发布问题的原因。我在网上看到了很多例子，我就是不明白。我的脑子可能被这个想法挡住了。

只需看一下 Ninject 主页的示例:

public class Samurai {
    public IWeapon Weapon { get; private set; }
    public Samurai(IWeapon weapon) {
        Weapon = weapon;
    }
}

public class WarriorModule : NinjectModule {
    public override void Load() {
        Bind< IWeapon >.To< Sword >();
    }
}

“武士”课对我来说还可以。 “NinjectModule”框架对我来说似乎没有必要。

我假设稍后在代码中我们将创建新的“Samurai”实例，将“Sword”实例传递给它，例如:

Samurai theWarrior = new Samurai(WarriorModule.GetInstance(IWeapon));//no coupling

可以替换为:

Samurai theWarrior = new Samurai(new Sword());//still no coupling

或者

Samurai theWarrior = new Samurai(GetWeaponFromXML());//no coupling yet

我缺少的部分是什么？您能否介绍一下我的应用程序中可能需要 Ioc 框架的一些场景？

谢谢。

4 个答案后更新:我真的很喜欢从你们那里得到的所有答案。我刚读了这篇文章 dependency-injection-dissection/那个家伙将它用于单元测试和您刚刚提供的 StackOverflow 链接，是的，我错过了大复杂性部分，所以让我自己自定义使用 IoC 框架。再次感谢。

我会投票给你的答案，但我只是收到一条橙色消息，说我不能。

感谢突出显示我发布的代码的人。

Answer 1

这是代码示例的问题。它们要么很复杂，你还没有解释你的观点，要么它们很琐碎，然后看起来毫无意义。

WarriorModule 所做的是将具体类型绑定(bind)到接口(interface)，因此当另一个类需要该接口(interface)的实现时，它会通过 IoC 容器自动接收。具有依赖关系的类对具体类型没有依赖关系，因此具有较低的耦合性和较高的可测试性。我想你已经知道了。

在您的替换方案中，Samurai 类未与剑类耦合，但调用代码仍然是。您可以将其推出另一个级别，但是该代码现在将具有依赖项，并且您的干预类现在必须编码所有依赖项。

IoC 容器对所有映射执行此操作，仅将其放在少数几个地方(模块类)。您的其余代码无需关心，无需依赖具体类型。

希望有帮助。