都快三年了，是吧?

在支持IoC框架的评论中，有50%的人不理解IoC和IoC框架之间的区别。我怀疑他们是否知道无需部署到应用服务器就可以编写代码 如果我们以最流行的Java Spring框架为例，IoC配置从XMl转移到代码中，现在看起来是这样的

“@ configuration 公共类AppConfig {

public @Bean TransferService transferService() {
    return new TransferServiceImpl(accountRepository());
}

public @Bean AccountRepository accountRepository() {
    return new InMemoryAccountRepository();
}

｝ ｀ 我们需要一个框架来做这件事，为什么?

You would need an IoC container if you needed to centralize the configuration of your dependencies so that they may be easily swapped out en mass. This makes the most sense in TDD, where many dependencies are swapped out, but where there is little interdependence between the dependencies. This is done at the cost of obfuscating the flow of control of object construction to some degree, so having a well organized and reasonably documented configuration is important. It is also good to have a reason to do this, otherwise, it is mere abstraction gold-plating. I have seen it done so poorly that it was dragged down to being the equivalent to a goto statement for constructors.

IoC框架非常棒，如果你想…

…扔掉类型安全。许多(?)IoC框架迫使您执行代码，如果您想确保所有东西都正确连接。“嘿!希望我已经把一切都设置好了，这样我对这100个类的初始化就不会在生产中失败，抛出空指针异常!” .．.在代码中使用全局变量(IoC框架都是关于改变全局状态的)。 .．.编写依赖关系不明确、难以重构的蹩脚代码，因为你永远不知道什么依赖什么。

IoC的问题在于，使用它的人过去常常编写这样的代码

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

这显然是有缺陷的，因为Foo和Bar之间的依赖是硬连接的。然后他们意识到编写这样的代码会更好

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

这也有缺陷，但不那么明显。 在Haskell中，Foo()的类型将是IO Foo，但你真的不想要IO部分，这应该是一个警告信号，如果你得到了它，你的设计有问题。

为了摆脱它(io部分)，获得ioc框架的所有优点，去掉它的所有缺点，你可以使用抽象工厂。

正确的解决方法应该是

data Foo = Foo { apa :: Bar }

或者

data Foo = forall b. (IBar b) => Foo { apa :: b }

和inject(但我不会叫它inject) Bar。

另外:观看Erik Meijer (LINQ的发明者)的视频，他说DI是为不懂数学的人准备的(我非常同意):http://www.youtube.com/watch?v=8Mttjyf-8P4

不像Spolsky先生，我不相信使用ioc框架的人很聪明——我只是认为他们不懂数学。

对我来说，使用IoC容器的最大好处(我个人使用Ninject)是消除了设置和其他类型的全局状态对象的传递。

我不为web编程，我的是一个控制台应用程序，在对象树的许多地方，我需要访问用户指定的设置或元数据，这些设置或元数据是在对象树的一个完全独立的分支上创建的。通过IoC，我简单地告诉Ninject将设置作为一个单例(因为它们总是只有一个实例)，在构造函数中请求设置或字典，然后立即…它们在我需要的时候神奇地出现了!

如果不使用IoC容器，我将不得不通过2,3，…传递设置和/或元数据。在它被需要它的对象实际使用之前，有n个对象。

DI/IoC容器还有许多其他好处，正如其他人在这里详细介绍的那样，从创建对象到请求对象的想法可能会令人难以置信，但使用DI对我和我的团队非常有帮助，所以也许您可以将其添加到您的库中!

在。net世界里AOP还不是很流行，所以对于依赖注入来说，一个框架是你唯一真正的选择，不管你是自己写一个框架还是使用另一个框架。

如果您使用AOP，则可以在编译应用程序时进行注入，这在Java中更为常见。

DI有很多好处，比如减少耦合，从而使单元测试更容易，但是您将如何实现它呢?你想用反射来自己做吗?

无论何时使用“new”关键字，您都是在创建一个具体的类依赖，您的头脑中应该敲响警钟。孤立地测试这个物体变得更加困难。解决方案是对接口进行编程并注入依赖项，这样对象就可以用实现该接口的任何东西进行单元测试。模拟)。

The trouble is you have to construct objects somewhere. A Factory pattern is one way to shift the coupling out of your POXOs (Plain Old "insert your OO language here" Objects). If you and your co-workers are all writing code like this then an IoC container is the next "Incremental Improvement" you can make to your codebase. It'll shift all that nasty Factory boilerplate code out of your clean objects and business logic. They'll get it and love it. Heck, give a company talk on why you love it and get everyone enthused.

如果你的同事还没有做DI，那么我建议你先专注于DI。宣传如何编写易于测试的干净代码。干净的DI代码是比较困难的部分，一旦做到了这一点，将对象连接逻辑从Factory类转移到IoC容器应该是相对简单的。