关于Unity也是如此。如果房子太大，你会听到房梁的吱吱声。

当人们开始大谈IoC代码看起来有多干净时，我从不感到惊讶，这些人在90年代曾说过c++中的模板是如何优雅的方式，但现在却会谴责它们是神秘的。呸!

就我个人而言，我使用IoC作为我的应用程序的某种结构图(是的，我也喜欢StructureMap;))。这使得在测试期间用Moq实现代替我通常的接口实现变得很容易。创建一个测试设置可以像对我的ioc -框架进行一个新的初始化调用一样简单，用一个mock代替任何一个测试边界类。

这可能不是IoC存在的目的，但这是我发现自己使用它最多的地方。

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

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

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

老实说，我没有发现有很多情况需要IoC容器，大多数情况下，它们只是增加了不必要的复杂性。

如果你只是用它来简化对象的构造，我要问，你是否在多个位置实例化了这个对象?单例不适合您的需要吗?您是否在运行时更改配置?(切换数据源类型等)。

如果是，那么您可能需要一个IoC容器。如果不是，那么您只是将初始化移到开发人员容易看到的地方。

谁说接口比继承好?假设您正在测试一个服务。为什么不使用构造函数DI，并使用继承创建依赖关系的模拟呢?我使用的大多数服务只有少数依赖项。以这种方式进行单元测试可以避免维护大量无用的接口，也意味着您不必使用Resharper来快速查找方法的声明。

我相信对于大多数实现来说，说IoC容器删除不需要的代码是一个神话。

首先，首先要设置容器。然后，您仍然必须定义需要初始化的每个对象。所以在初始化时不保存代码，而是移动它(除非你的对象被使用了不止一次)。单例是否更好?)然后，对于以这种方式初始化的每个对象，都必须创建和维护一个接口。

有人有什么想法吗?

I'm a recovering IOC addict. I'm finding it hard to justify using IOC for DI in most cases these days. IOC containers sacrifice compile time checking and supposedly in return give you "easy" setup, complex lifetime management and on the fly discovering of dependencies at run time. I find the loss of compile time checking and resulting run time magic/exceptions, is not worth the bells and whistles in the vast majority of cases. In large enterprise applications they can make it very difficult to follow what is going on.

我不相信集中化的说法，因为你可以通过为你的应用程序使用一个抽象工厂，并虔诚地将对象创建推迟到抽象工厂，即进行适当的DI，来非常容易地集中静态设置。

为什么不像这样做静态无魔法DI:

interface IServiceA { }
interface IServiceB { }
class ServiceA : IServiceA { }
class ServiceB : IServiceB { }

class StubServiceA : IServiceA { }
class StubServiceB : IServiceB { }

interface IRoot { IMiddle Middle { get; set; } }
interface IMiddle { ILeaf Leaf { get; set; } }
interface ILeaf { }

class Root : IRoot
{
    public IMiddle Middle { get; set; }

    public Root(IMiddle middle)
    {
        Middle = middle;
    }

}

class Middle : IMiddle
{
    public ILeaf Leaf { get; set; }

    public Middle(ILeaf leaf)
    {
        Leaf = leaf;
    }
}

class Leaf : ILeaf
{
    IServiceA ServiceA { get; set; }
    IServiceB ServiceB { get; set; }

    public Leaf(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }
}


interface IApplicationFactory
{
    IRoot CreateRoot();
}

abstract class ApplicationAbstractFactory : IApplicationFactory
{
    protected abstract IServiceA ServiceA { get; }
    protected abstract IServiceB ServiceB { get; }

    protected IMiddle CreateMiddle()
    {
        return new Middle(CreateLeaf());
    }

    protected ILeaf CreateLeaf()
    {
        return new Leaf(ServiceA,ServiceB);
    }


    public IRoot CreateRoot()
    {
        return new Root(CreateMiddle());
    }
}

class ProductionApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new ServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new ServiceB(); }
    }
}

class FunctionalTestsApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new StubServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new StubServiceB(); }
    }
}


namespace ConsoleApplication5
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ProductionApplication();
            var root = factory.CreateRoot();

        }
    }

    //[TestFixture]
    class FunctionalTests
    {
        //[Test]
        public void Test()
        {
            var factory = new FunctionalTestsApplication();
            var root = factory.CreateRoot();
        }
    }
}

容器配置是抽象工厂实现，注册是抽象成员的实现。 如果您需要一个新的单例依赖项，只需向抽象工厂添加另一个抽象属性即可。如果你需要一个瞬态依赖，只需添加另一个方法并将其作为Func<>注入即可。

优点:

所有的设置和对象创建配置都是集中的。 配置只是代码 编译时检查使其易于维护，因为您不会忘记更新注册。 没有运行时反射魔法

我建议持怀疑态度的人尝试下一个新项目，诚实地问问自己什么时候需要这种容器。稍后很容易引入IOC容器，因为您只是用IOC容器配置模块替换了一个工厂实现。

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