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容器采用了一个简单、优雅且有用的概念，并使其成为您需要用200页手册学习两天的东西。

我个人很困惑，为什么IoC社区把Martin Fowler写的一篇漂亮、优雅的文章变成了一堆复杂的框架，通常只有200-300页的手册。

我尽量不去评判(哈哈!)，但我认为使用IoC容器的人(A)非常聪明，(B)对不如他们聪明的人缺乏同理心。对他们来说，每件事都很有意义，所以他们很难理解许多普通程序员会感到困惑的概念。这是知识的诅咒。理解IoC容器的人很难相信还有人不理解它。

The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode. For example, suppose you have two versions of your database access classes... one version which logged aggressively and did a lot of validation, which you used during development, and another version without logging or validation that was screamingly fast for production. It is nice to be able to switch between them in one place. On the other hand, this is a fairly trivial problem easily handled in a simpler way without the complexity of IoC containers.

我相信如果您使用IoC容器，您的代码将变得(坦白地说)难以阅读。为了弄清楚代码要做什么，您必须查看的地方的数量至少增加了一个。在天堂的某个地方，一位天使在呼喊。

因为所有的依赖关系都是清晰可见的，所以它可以促进创建松散耦合的组件，同时在整个应用程序中易于访问和重用。

I've found that correctly implementing Dependency Injection tends to force programmers to use a variety of other programming practices that help to improve the testability, flexibility, maintainability, and scalability of code: practices like the Single Responsibility Principle, Separations of Concerns, and coding against APIs. It feels like I'm being compelled to write more modular, bite-sized classes and methods, which makes the code easier to read, because it can be taken in bite-sized chunks.

但它也倾向于创建相当大的依赖树，通过框架(特别是如果您使用约定)比手工管理要容易得多。今天我想在LINQPad中快速测试一些东西，我认为创建内核并在我的模块中加载太麻烦了，最后我手写了这个:

var merger = new SimpleWorkflowInstanceMerger(
    new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
    new WorkflowAnswerRowUtil(
        new WorkflowFieldAnswerEntMapper(),
        new ActivityFormFieldDisplayInfoEntMapper(),
        new FieldEntMapper()),
    new AnswerRowMergeInfoRepository());

回想起来，使用IoC框架会更快，因为模块按照约定定义了几乎所有这些东西。

Having spent some time studying the answers and comments on this question, I am convinced that the people who are opposed to using an IoC container aren't practicing true dependency injection. The examples I've seen are of practices that are commonly confused with dependency injection. Some people are complaining about difficulty "reading" the code. If done correctly, the vast majority of your code should be identical when using DI by hand as when using an IoC container. The difference should reside entirely in a few "launching points" within the application.

换句话说，如果你不喜欢IoC容器，你可能没有按照它应该做的方式来做依赖注入。

另一点:如果你在任何地方都使用反射，依赖注入真的不能手工完成。虽然我讨厌反射对代码导航造成的影响，但您必须认识到，在某些领域，它确实是无法避免的。ASP。例如，NET MVC尝试通过对每个请求的反射来实例化控制器。要手动进行依赖注入，你必须让每个控制器都成为“上下文根”，如下所示:

public class MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController()
    {
        _simpleMerger = new SimpleWorkflowInstanceMerger(
            new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
            new WorkflowAnswerRowUtil(
                new WorkflowFieldAnswerEntMapper(),
                new ActivityFormFieldDisplayInfoEntMapper(),
                new FieldEntMapper()),
            new AnswerRowMergeInfoRepository())
    }
    ...
}

现在将其与允许DI框架为你做这件事进行比较:

public MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController(ISimpleWorkflowInstanceMerger simpleMerger)
    {
        _simpleMerger = simpleMerger;
    }
    ...
}

使用DI框架，注意:

I can unit-test this class. By creating a mock ISimpleWorkflowInstanceMerger, I can test that it gets used the way I anticipate, without the need for a database connection or anything. I use far less code, and the code is much easier to read. If one of my dependency's dependency's changes, I don't have to make any changes to the controller. This is especially nice when you consider that multiple controllers are likely to use some of the same dependencies. I never explicitly reference classes from my data layer. My web application can just include a reference to the project containing the ISimpleWorkflowInstanceMerger interface. This allows me to break the application up into separate modules, and maintain a true multi-tier architecture, which in turn makes things much more flexible.

A typical web application will have quite a few controllers. All of the pain of doing DI by hand in each controller will really add up as your application grows. If you have an application with only one context root, which never tries to instantiate a service by reflection, then this isn't as big a problem. Nevertheless, any application that uses Dependency Injection will become extremely expensive to manage once it reaches a certain size, unless you use a framework of some kind to manage the dependency graph.

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框架的人很聪明——我只是认为他们不懂数学。

As you continue to decouple your classes and invert your dependencies, the classes continue to stay small and the "dependency graph" continues to grow in size. (This isn't bad.) Using basic features of an IoC container makes wiring up all these objects trivial, but doing it manually can get very burdensome. For example, what if I want to create a new instance of "Foo" but it needs a "Bar". And a "Bar" needs an "A", "B", and "C". And each of those need 3 other things, etc etc. (yes, I can't come up with good fake names :) ).

使用IoC容器为您构建对象图可以大大降低复杂性，并将其推到一次性配置中。我只需说“给我创建一个Foo”，它就会计算出构建一个Foo需要什么。

有些人将IoC容器用于更多的基础设施，这对于高级场景来说是很好的，但在这些情况下，我同意它会使新开发人员难以阅读和调试代码。