为什么我需要一个IoC容器而不是直接使用DI代码？
为什么我需要一个IoC容器而不是直接使用DI代码？
当你使用DI来解耦你的类并提高可测试性时，很可能没有人强迫你使用DI容器框架。简单来说，你更偏向于简单性，这通常是一件好事。
如果你的系统变得越来越复杂，手动进行DI变得繁琐（也就是增加了维护成本），那么你可以考虑使用DI容器框架，权衡一下团队学习成本。
如果你需要更多地控制依赖的生命周期（也就是如果你觉得需要实现单例模式），那么可以考虑使用DI容器。
如果你使用DI容器，只使用你需要的功能。如果在代码中进行配置就足够了，那就不要使用XML配置文件。坚持使用构造函数注入。Unity或StructureMap的基本使用可以压缩为几页代码。
这里有一篇Mark Seemann的博客文章讲述了这个问题：何时使用DI容器
非常好的回答。我唯一不同意的观点是手动进行注入是否可以被认为是更简单或不费力的。
+1. 这是这里最好的回答之一。感谢提供博客文章链接。
+1，对于不偏袒任何一方的观点。IoC容器并不总是好的，也不总是坏的。如果你没有看到需要使用它的理由，就不要使用。只需要知道有这个工具在那里，如果你需要时可以使用它。
为什么我需要一个IoC容器而不是直接使用DI代码？
IoC容器是一个将简单、优雅和有用的概念变成需要花两天时间研究200页手册的东西。它们是由Martin Fowler的一篇文章演变而来的，而IoC社区将其变成了一堆复杂的框架，通常带有200到300页的手册。
使用IoC容器的人很聪明，但对于那些没有那么聪明的人来说，他们缺乏同理心。对于他们来说，一切都很明显，所以他们难以理解许多普通程序员会觉得这些概念很困惑。这是所谓的“知识诅咒”。了解IoC容器的人很难相信有人不了解它。
使用IoC容器最有价值的好处是你可以在一个地方进行配置切换，比如在测试模式和生产模式之间进行切换。例如，假设你有两个版本的数据库访问类……一个版本在开发过程中记录了大量信息并进行了大量验证，而另一个版本没有记录或验证，在生产环境中非常快速。能够在一个地方进行切换是很好的。另一方面，这是一个相当琐碎的问题，可以在没有IoC容器复杂性的情况下以更简单的方式处理。
我认为如果你使用IoC容器，你的代码会变得更难读。你需要查看的代码位置至少增加了一个。在天堂的某个地方，一个天使大喊出来。
可能不同的人对世界有不同的看法。使用IoC的人像意识形态者一样，希望世界能跟随他们的脚步，还有像我这样（以及其他开发人员）的人，他们陷在意识形态和现实之间。
开始尝试使用DI框架（StructureMap），它声称是最古老的IoC容器，但是考虑到我想要的东西，它的复杂性令人震惊。相反，我正在编写一个非常简单的服务定位器。也许其他的IoC容器更有意义，但是我真的看不出来它的意义，也没有时间花几天时间来弄清楚如何使用它，而这将使代码阅读起来更加复杂。
Martin Fowler确实没有发明IoC。
我认为你对事实有些混淆，IoC和容器先出现，然后是Martin的论文。
大多数容器让你非常快速地开始使用。使用autofac、structure map、unity、ninject等，你应该能够在大约5分钟内让容器工作。是的，它们有高级功能，但你不需要这些功能就可以入门。
为什么这个ninject.codeplex.com/Wiki/...被认为是火箭科学，我无法理解。
我以前用过structure map和Unity。你可以很简单地做到基本的事情（读取他们的FAQ只需要几行代码），但是如果你试图将其适应太多情况，它会很快变得复杂。
我是IoC容器的粉丝，但我不认为它们“很容易理解”（概念相当抽象，涉及到软件开发的核心）……此外，我认为Joel的答案会鼓励人们忽视IoC背后的重要思想，所以我给他点了个踩。
此外，如果有人正在编写可测试的代码，遵循SRP等（我认为大多数人都认为这是好的），你的类基本上总会有大量的接口依赖。我问：没有IoC框架，你怎么连接所有的类？
没有容器的IoC跟“读200页手册”相比，更加复杂和耗时。更不用说容器早在Martin Fowler的文章之前就出现了，它是设计模式的一部分。所以，如果Spolsky先生想要说IoC过于复杂，我们可能不同意，但是他并没有这么说……他完全错了。
Joel，我曾经和你有同样的想法。然后我用了几分钟的时间来弄清楚如何运行最基本的设置，惊讶地发现80/20法则正在起作用。它使代码更清晰，尤其是在简单的情况下。
我从事编程不到两年，我阅读了Ninject的wiki并理解了它。从那以后，我已经在很多地方使用了DI。你看到了吗？不到两年的时间，阅读维基上的几页内容。我不是什么大神。我不认为自己是个天才，但我很容易理解它。我无法想象真正理解面向对象编程的人无法掌握它。另外，你所提到的200-300页手册是指什么？我从来没有见过这样的手册。我使用过的所有IoC容器都非常简洁和简明。
所以，如果你不使用IoC容器，那是因为你不够聪明，无法理解它们，但是如果你使用IoC容器（并且喜欢每一秒），那是因为你太聪明了？
Joel-我不理解为什么你认为它使代码更难阅读。代码实际上更容易理解。所有的依赖都只是通过构造函数注入。不需要追踪依赖关系。设置只需要2-3行代码，这取决于需要创建的项目数量。
我不知道你们为什么质疑Joel。他知道我们的内心活动，就像圣诞老人一样。他知道我们没有办法理解IoC，就像我们早上穿裤子一样需要帮助。谢谢Joel，你提醒我自己有多蠢，我已经太自以为是了。
Joel-我假设你已经很久没有看过IoC容器了，因为过去几年中已经发生了很大变化。它们现在很容易配置，主要是由于约定。DI很好；让一种好的实践更容易实现和维护。为什么传递你的代码的具体实现，当一个第三方库可以为你完成呢？IoC容器会：管理整个图；无需在类中添加贫民的DI构造函数；减少代码行数；将你的依赖关系集中在代码库中的一个简洁位置。
Joel-你声称IoC的主要好处是在测试中交换实现，这表明你不理解IoC。IoC是关于关注点分离和摆脱当你想要添加/删除依赖关系时重新编写所有实例化链的束缚。更不用说其他众多的好处了。
我真的不明白为什么我会同意参加StackOverflow DevDays。
我需要为DevDays制作一个“我爱VBA”的T恤。
哇……太过于反对了。我认为这可能是一种不跟随潮流的实验。老实说，我从事全职开发还不到两年（现在将近三年），我已经使用了3个不同的.Net IoC容器。我不声称理解它们所做的一切。但是我知道它们简化了我的开发。同样，我使用SQL Server。但是我不会声称了解现代RDBMS系统的所有复杂性。
Joel的观点在某种程度上是正确的，IoC容器可以使简单的事情变得复杂，并且使代码更难追踪（因为许多代码路径变得间接）。但是它们有其他的好处，比如方便地构建应用程序资源。你必须在某个地方处理它们。我也不认为它们太复杂，但是我在一个地方工作，那里所有的IoC都是反过来编码的(!)所以也许你不应该听我的。
你提出了一个很好的小项目的观点。然而，使用IoC容器的复杂性成本在中大型项目中是可以克服的，并且在价值上超过了它本身。
有一些评论者支持Joel的论点，引用了KISS原则。这些人没有意识到使用IoC容器才是KISS的方式。KISS代表“保持简单，傻瓜”，而不是“从简单开始，最终变成一团糟，傻瓜”。IoC容器帮助您在应用程序不断发展的过程中保持简单。我相信Joel会支持SOSEUWMS，因为它有助于保持缺陷追踪器需求量高。
问题不是我难以相信有人不了解IoC，而是我难以相信有人不愿意尝试理解。确实，这并不难。我认为最大的问题是这个名字听起来很吓人。
我使用了一个IoC容器，我并不聪明。
对于简单的事情，使用轻量级的工具。检查一下这个小而简单的IoC容器，它支持IoC、DI和自动装配：mentacontainer.soliveirajr.com
这个答案证明了几乎一半的社区将downvote按钮视为“我不同意”的意思，而不是“这个答案没有帮助”。每当我面对这个事实时，我都会感到困扰，我们只是复杂的灵长类动物。
对于简单的事情，使用轻量级的工具。检查一下这个小而简单的IoC容器，它支持IoC、DI和自动装配：mentacontainer.soliveirajr.com
这个答案证明了几乎一半的社区将downvote按钮视为“我不同意”的意思，而不是“这个答案没有帮助”。每当我面对这个事实时，我都会感到困扰，我们只是复杂的灵长类动物。
对于简单的事情，使用轻量级的工具。检查一下这个小而简单的IoC容器，它支持IoC、DI和自动装配：mentacontainer.soliveirajr.com
这个答案证明了几乎一半的社区将downvote按钮视为“我不同意”的意思，而不是“这个答案没有帮助”。每当我面对这个事实时，我都会感到困扰，我们只是复杂的灵长类动物。
对于简单的事情，使用轻量级的工具。检查一下这个小而简单的IoC容器，它支持IoC、DI和自动装配：mentacontainer.soliveirajr.com
这个答案证明了几乎一半的社区将downvote按钮视为“我不同意”的意思，而不是“这个答案没有帮助”。每当我面对这个事实时，我都会感到困扰，我们只是复杂的灵长类动物。
IOC是一种优秀的技术，但是当有人搞砸它时，它真的太可怕了，而且最终总有人会搞砸它。它也可能使代码中发生的事情变得模糊不清。在我看来，如果你能够快速地在几秒钟内查看一段代码并理解它，而无需深入到源代码的其余部分，这总是更好的。
为什么需要使用IoC容器而不是直接使用DI代码？
在上面的内容中，问题出现的原因是手动管理依赖关系链变得越来越复杂，即使使用工厂模式，代码的重复性也不值得。解决方法是使用IoC容器，它可以简化依赖注入的过程。
另外，文章还提到了一个场景，即将实体或模型对象绑定到智能UI，并解释了为什么使用IoC工具可以更轻松地实现这一过程。通过将属性设置为虚拟属性，可以自动生成实现INotifyPropertyChanged接口的代码，从而简化了代码的编写过程。文章还提到了使用IoC工具进行AOP的其他一些有趣用途，如声明性和嵌套数据库事务、声明性和嵌套工作单元、日志记录和前/后置条件（设计按合同）。
因此，文章的主要观点是使用IoC容器可以简化依赖注入过程，提高代码的可维护性，并提供更多的灵活性和功能，例如自动生成实现特定接口的代码。同时，文章还提到了一些使用IoC工具进行AOP的有趣用途。
原文链接：https://stackoverflow.com/questions/20241