依赖注入与工厂或目录

Question

我一直想知道是否有人在任何非玩具项目中使用 DI/IoC，他可以在其中选择实现风格（而不是由库或开发要求强制执行）。

毕竟，如果我们想要一个类的单个实例，工厂只是完美的机制，而如果我们想要一个特定的实例，目录服务是完美的机制。

那么添加 Spring/Guice/etc 有什么大不了的。进入这个并为我们自己创造另一个依赖？ （或者也许我完全无法理解他们的 DI 方法......）

谢谢。

Answer 1

DI (Dependency Inversion) principle 对框架只字未提，只是声称：

1. 高级模块不应依赖于低级模块。两者都应该依赖于抽象。
2. 抽象不应依赖于细节。细节应该取决于抽象。

控制反转 (IoC) 原则也与减少软件中类之间的耦合有关。

有许多模式可用于使您的类保持低耦合并遵循 DI 或 IoC 原则。如何实现这一目标是您的责任。 Inversion of Control Containers and the Dependency Injection pattern 是其中的一部分。

毕竟，如果我们想要一个类的单个实例，工厂只是完美的机制，而如果我们想要一个特定的实例，目录服务是完美的机制。

而 Factory 被视为 implementation techniques of inversion of comtrol principle 之一。

我一直想知道是否有人在任何非玩具项目中使用 DI/IoC，他可以在其中选择实现风格（而不是由库或开发要求强制执行）。

我看到很多使用 DI\IoC 容器\框架的企业应用程序。这些框架提供了关心对象创建（如Factory）、其生命周期（如Singleton）、注入依赖项、保存所有对象列表（如Registry）的基础设施

那么添加 Spring/Guice/etc 有什么大不了的。进入这个并为我们自己创造另一个依赖？

当你使用它时，你的类不依赖于任何 IoC 容器。 IoC 容器只是基础设施层的一部分。

我认为，避免使用 IoC 容器的唯一原因是公司的规则和协议限制您使用 3rd 方库。