我正在调查依赖注入。而且我发现：引用的大多数依赖注入的例子，我们也可以使用工厂模式来解决。
您能帮我比较一下 DI 和工厂模式之间的优缺点吗？我应该总是选择依赖注入而不是工厂模式吗？还是取决于指定的项目？
我如何知道最佳解决方案是什么？什么是最佳做法？
【问题讨论】：
标签： design-patterns dependency-injection
让我们看看它们之间的区别。
使用 DI，对象在外部创建并“注入”以供客户端对象使用。 注入通常通过构造函数完成。
但是，在复杂的情况下，通常会注入一个 DI 容器来创建依赖对象，包括所有的子依赖。所以它看起来像抽象工厂！
使用抽象工厂，一个具体工厂类的实例被注入，依赖对象由客户端对象实例化。
所以 DI 和抽象工厂几乎相同，当您考虑到在这两种情况下，工厂对象都被传递给客户端以使其能够创建其依赖项。
仅在简单的情况下，依赖对象在外部创建并传递给客户端对象。这就是策略模式的工作原理。
由于 DI 容器现在如此流行，并且在框架中得到如此广泛的使用，它们已经有效地取代了抽象工厂，至少作为一种经常被提及的模式。 DI 容器是比抽象工厂想象的要复杂得多的实体（我相信）。
所以没有最佳实践！
【讨论】：
我喜欢在接口上使用简单的依赖注入。 只需将实现接口的对象传递给构造函数即可。
这具有额外的优势，您可以轻松地模拟界面并在构建服务器/计算机上运行测试。由于 Xamarin 的部署需要很长时间，因此请尽可能多地使用单元测试。
【讨论】：
你应该同时使用。
Factory 是关于根据给定参数找到接口的正确实现并返回它的实例。这是解决类不能同时负责实例化自身和做其他事情的问题的一种方法，因为它违反了 SRP。
DI 通常通过将参数传递给实际类的构造函数来注入依赖项。它是必需的，因为高级代码不应该知道它使用哪个低级代码的实现，只是这个实现与某个接口相呼应。否则我们将违反 DIP。
所以工厂与 DI 非常兼容。实际上 DI 容器只是一个自动化工厂，它从注解、配置文件等中提取信息，以便能够创建 Applcation 实例并注入其依赖项。当然它的依赖也有依赖等等，所以如果你手动编写它会是一个很长的代码，所以它很有可能是一个上帝的对象。你可以通过定义工厂来解决这个问题，这会使其更短，但不知何故人们更喜欢自动化。
【讨论】：