我正在彻底阅读关于DI的内容，看起来很有趣。到目前为止，我完全没有它。
我看到的所有例子都与JNDI有关，以及DI如何帮助您提高灵活性。
您通过DI解决的现实生活中的应用/问题在其他方面很难解决？
更新
到目前为止所有的答案都在教育，但是为了重新解释这个问题，我正在寻找编程生涯中的例子，这让你说“这个问题最好用DI框架来解决”。
答案 0 :(得分：24)
就在前几天，我决定阅读依赖注入。在那之前，我只知道这个词。老实说，我对Martin Fowler article的反应是，“就是这样？”
我必须同意James Shore：
对于5美分概念，“依赖注入”是一个25美元的术语。
这并不意味着它是一个糟糕的概念。但严重的是，当实例A需要与另一个实例B一起使用时，它归结为这些选择：
让A 找到 B：
这意味着B必须是全球性的。恶
让A 创建 B：
好的，如果只有A需要B。只要C还需要B，请在此列表中将A替换为C。请注意，测试用例是C，所以如果你想测试，那么这个选择也会消失。
将 B提交给A：
这是依赖注入。
我错过了什么吗？ （请注意，我来自Python世界，所以也许我没有看到特定于语言的点。）
答案 1 :(得分：7)
昨天我在公交车上找到了一部手机。失去它的人对拥有她的手机的人一无所知。我打电话给她爸爸告诉他我有他女儿的手机。所以我把依赖从我身上注入了他。典型的例子是好莱坞原则“不要打电话给我们（因为你不能！），我们称你为”。后来他来接他的女儿电话。
我称之为依赖注入我解决的现实世界问题，不是吗？
在我看来，DI不是解决问题的方法，对此我们不会有另一种解决方案。工厂可以是解决此类问题的另一种方式。 所以对你的问题没有真正的答案，因为DI只是其他方式的一种方式。它只是一个非常时髦，但非常优雅的方式。
当我有这个需要SQLMapper的DAO时，我真的很喜欢DI。我只需要将不同的映射器注入到父类中一次，其余的由配置完成。节省了我很多时间和LOC，但我仍然不能说这是一个没有其他解决方案的问题。
答案 2 :(得分：4)
我一直使用依赖注入进行测试。当你有一堆你不想直接连接在一起的大型系统时，它也非常有用（非常宽松的耦合）。
如果你正在使用Java，我会推荐Google Guice，因为它非常多。对于C ++，我建议Qt IOC。对于.NET，Castle Project提供了一个很好的IOC系统。基本上到处都有一个Spring实现，但这很无聊。
答案 3 :(得分：3)
DI允许您创建可以配置和重新配置的应用程序，而无需触及代码库本身。不仅仅是网址或设置;通用对象可以用代码编写，然后通过XML文件“自定义”或配置，以实现给定案例所需的特定结果。
例如，我可以创建一个RegexDetective类，其中查找的实际正则表达式在setter中提供，然后在我的Spring DI XML文件中，为RegexDetective.setRegex（）定义一个实际的正则表达式，用于部署SleuthApp去伦敦。几天后，我可以返回并更新XML文件中的正则表达式，以便将另一个SleuthApp部署发送到西伯利亚。
DI还允许在XML中的代码库之外以类似的方式定义接口的特定实现，以修改应用程序的行为而无需实际触及代码，例如设置Detective接口的AngryDetective或ArcticDetective实现，在DI XML文件中。
答案 4 :(得分：2)
我们为不同的国家/地区提供多媒体服务。我们为每个人运行相同的代码，但有时，业务规则因国家/地区而异。在这种情况下，我们为一个客户端或另一个客户端注入不同的Spring MVC Interceptor。
然后，在部署阶段，脚本根据文件的最后一个字母“选择”需要哪个DI文件（ fr 为法国， ch 为瑞士等......）
这是我在DI中看到的唯一好处。我不是DI的粉丝。
答案 5 :(得分：1)
我已经使用Spring的IoC（DI）容器来处理我开发的最后三个网络应用程序。我认为它不适合某种特定类型的问题，而是解决问题的另一种方式。正如您所说，对大型系统采用更灵活的方法。我个人最喜欢的DI功能是你可以准备更好的单元测试，因为你的课程是高度分离的。对我来说同样重要的是代码重用。由于我在许多应用程序中使用容器，因此我可以使用相同的组件并知道它们的依赖项将在外部提供。
答案 6 :(得分：0)
在使用DI的大型多模块应用程序中，模块仅依赖于其类的协作者的接口，会削减编译时依赖关系图。
在框架（调用“您的”功能代码，而不是调用库的功能代码）的上下文中，这是必需的。您的代码可以编译对框架的依赖关系，但是我们都知道框架（在您手中）无法编译代码的依赖项; - ）
答案 7 :(得分：0)
我主要使用DI来方便测试。此外，它还促进了对服务调用进行存根的模型，以提供隔离和独立于服务开发实现的能力。