我认为IoC的大部分价值都是通过使用DI获得的。既然你已经这样做了，剩下的好处是递增的。

你得到的值将取决于你正在处理的应用程序的类型:

For multi-tenant, the IoC container can take care of some of the infrastructure code for loading different client resources. When you need a component that is client specific, use a custom selector to do handle the logic and don't worry about it from your client code. You can certainly build this yourself but here's an example of how an IoC can help. With many points of extensibility, the IoC can be used to load components from configuration. This is a common thing to build but tools are provided by the container. If you want to use AOP for some cross-cutting concerns, the IoC provides hooks to intercept method invocations. This is less commonly done ad-hoc on projects but the IoC makes it easier.

我以前写过这样的功能，但如果我现在需要这些功能中的任何一个，我宁愿使用一个预先构建并经过测试的工具，如果它适合我的架构的话。

正如其他人所提到的，您还可以集中配置希望使用的类。虽然这可能是一件好事，但代价是误导和复杂化。大多数应用程序的核心组件都没有被替换，因此很难做出取舍。

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

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

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的其他一些有趣的用法:

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

我认为IoC的大部分价值都是通过使用DI获得的。既然你已经这样做了，剩下的好处是递增的。

你得到的值将取决于你正在处理的应用程序的类型:

For multi-tenant, the IoC container can take care of some of the infrastructure code for loading different client resources. When you need a component that is client specific, use a custom selector to do handle the logic and don't worry about it from your client code. You can certainly build this yourself but here's an example of how an IoC can help. With many points of extensibility, the IoC can be used to load components from configuration. This is a common thing to build but tools are provided by the container. If you want to use AOP for some cross-cutting concerns, the IoC provides hooks to intercept method invocations. This is less commonly done ad-hoc on projects but the IoC makes it easier.

我以前写过这样的功能，但如果我现在需要这些功能中的任何一个，我宁愿使用一个预先构建并经过测试的工具，如果它适合我的架构的话。

正如其他人所提到的，您还可以集中配置希望使用的类。虽然这可能是一件好事，但代价是误导和复杂化。大多数应用程序的核心组件都没有被替换，因此很难做出取舍。

我使用IoC容器，并欣赏其功能，但不得不承认我注意到了权衡:我的代码在类级别变得更加清晰，而在应用程序级别变得不那么清晰(即可视化控制流)。

都快三年了，是吧?

在支持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();
}

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