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

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

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

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

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

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

有人有什么想法吗?

哇，真不敢相信乔尔会喜欢这个

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

在这:

var svc = IoC.Resolve<IShippingService>();

许多人没有意识到你的依赖链可能会变成嵌套的，手动连接它们很快就会变得笨拙。即使使用工厂，重复代码也是不值得的。

IoC容器可以很复杂，是的。但是对于这个简单的例子，我已经证明了它非常简单。

好吧，让我们进一步证明这一点。假设您有一些想要绑定到智能UI的实体或模型对象。这个智能UI(我们称它为Shindows Morms)希望你实现INotifyPropertyChanged，这样它就可以进行更改跟踪并相应地更新UI。

"好吧，听起来没那么难"于是你开始写。

你可以这样开始:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime CustomerSince { get; set; }
    public string Status { get; set; }
}

．．结果是这样的:

public class UglyCustomer : INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            string oldValue = _firstName;
            _firstName = value;
            if(oldValue != value)
                OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            string oldValue = _lastName;
            _lastName = value;
            if(oldValue != value)
                OnPropertyChanged("LastName");
        }
    }

    private DateTime _customerSince;
    public DateTime CustomerSince
    {
        get { return _customerSince; }
        set
        {
            DateTime oldValue = _customerSince;
            _customerSince = value;
            if(oldValue != value)
                OnPropertyChanged("CustomerSince");
        }
    }

    private string _status;
    public string Status
    {
        get { return _status; }
        set
        {
            string oldValue = _status;
            _status = value;
            if(oldValue != value)
                OnPropertyChanged("Status");
        }
    }

    protected virtual void OnPropertyChanged(string property)
    {
        var propertyChanged = PropertyChanged;

        if(propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(property));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

这是令人作呕的管道代码，我认为如果你手写这样的代码，你就是在从客户那里偷东西。有更好更聪明的工作方式。

听过“更聪明地工作，而不是更努力地工作”这句话吗?

想象一下，你团队里有个聪明人说:“这有个更简单的方法”

如果你让你的财产是虚拟的(冷静点，这没什么大不了的)，那么我们就可以自动地编织财产行为。(这被称为AOP，但是不要担心它的名字，专注于它将为你做什么)

根据你使用的IoC工具，你可以这样做:

var bindingFriendlyInstance = IoC.Resolve<Customer>(new NotifyPropertyChangedWrapper());

噗!所有手动INotifyPropertyChanged BS现在都自动为您生成，在对象的每个虚拟属性setter上。

这是魔法吗?是的!如果您相信这段代码完成了它的工作，那么您就可以安全地跳过所有属性包装的繁文缛节。你有业务问题要解决。

IoC工具用于AOP的其他一些有趣的用法:

声明式和嵌套的数据库事务 声明性和嵌套的工作单元 日志记录 前/后条件(按合同设计)

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

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

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

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

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

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

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

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

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

有人有什么想法吗?

我知道这是一个相当老的帖子，但它似乎仍然相当活跃，我想我可以贡献一些在其他回答中没有提到的观点。

我同意依赖注入的好处，但我更喜欢自己构造和管理对象，使用与Maxm007在回答中概述的模式相似的模式。我发现了使用第三方容器的两个主要问题:

1) Having a 3rd party library manage the lifetime of your objects "automagically" can lend itself to unexpected results. We have found that especially in large projects, you can have vastly more copies of an object than you expect, and more than you would if you were manually managing the lifecycles. I'm sure this varies depending on the framework used, but the problem exists nonetheless. This can also be problematic if your object holds resources, data connections, etc., since the object can sometimes live longer than you expect. So inevitably, IoC containers tend to increase the resource utilization and memory footprint of an application.

2) IoC containers, in my opinion, are a form of "black box programming". I have found that in particular, our less experienced developers tend to abuse them. It allows the programmer to not have to think about how objects should relate to each other or how to decouple them, because it provides them with a mechanism in which they can simply grab any object they want out of thin air. Eg, there may be a good design reason that ObjectA should never know about ObjectB directly, but rather than creating a factory or bridge or service locator, an inexperienced programmer will simply say "no problem, I'll just grab ObjectB from the IoC container". This can actually lead to increased object coupling, which is what IoC is supposed to help prevent.

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

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