我一直想知道是否有人在任何非玩具项目中使用DI / IoC，他可以选择实施方式（而不是由图书馆或开发要求强制执行）。
毕竟，如果我们想要一个类的单个实例，工厂就是一个完美的机制，如果我们想要一个特定的实例，那么目录服务就是完美的机制。
那么添加Spring / Guice / etc有什么大不了的。进入这个并为自己创造另一个依赖？ （或许我完全不理解他们的DI方法......）
感谢。
答案 0 :(得分：1)
DI (Dependency Inversion) principle对框架一无所知，只是声称：
- 高级模块不应依赖于低级模块。两者都应该取决于抽象。
- 抽象不应该依赖于细节。细节应该取决于抽象。
控制反转（IoC）原则还与减少软件中类之间的耦合有关。
有许多模式用于保持您的类低耦合并遵循DI或IoC原则。如何实现这一目标是你的责任。 Inversion of Control Containers and the Dependency Injection pattern是其中的一部分。
毕竟，如果我们想要一个类的单个实例，工厂就是完美的机制，如果我们想要一个特定的实例，目录服务就是完美的机制。
工厂被认为是implementation techniques of inversion of comtrol principle之一。
我一直想知道是否有人在任何非玩具项目中使用DI / IoC，他可以选择实施方式（而不是由图书馆或开发要求强制执行）。
我看到许多使用DI \ IoC容器\框架的企业应用程序。这些框架提供了一个关注对象创建的基础结构（如Factory），它的生命周期（如Singleton），注入依赖项，保存所有对象的列表（如Registry）
那么添加Spring / Guice / etc有什么大不了的。进入这个并为自己创造另一个依赖？
当您使用它时，您的类与任何IoC容器都没有依赖关系。 IoC容器只是您的基础设施层的一部分。
我认为，避免使用IoC容器的唯一原因是当您被限制按公司的规则和协议使用第三方库时。