我正在调查依赖注入。我发现:在大多数引用依赖注入用法的示例中,我们也可以使用工厂模式来解决问题。
请帮我比较一下依赖注入和工厂模式的优缺点。我应该始终选择依赖注入而不是工厂模式吗?还是这取决于具体的项目?
如何确定最佳解决方案?这方面有什么最佳实践吗?
我正在调查依赖注入。我发现:在大多数引用依赖注入用法的示例中,我们也可以使用工厂模式来解决问题。
请帮我比较一下依赖注入和工厂模式的优缺点。我应该始终选择依赖注入而不是工厂模式吗?还是这取决于具体的项目?
如何确定最佳解决方案?这方面有什么最佳实践吗?
你应该同时使用工厂模式和依赖注入。
工厂模式的作用是根据给定参数找到接口的正确实现,并返回其实例。它是解决一个类既要实例化自己又要做其他事情的问题的一种方式,因为这会违反SRP原则。
依赖注入通常是通过将参数传递给实际类的构造函数来注入依赖项。需要这样做是因为高级代码不应该知道它使用低级代码的哪个实现,而只需要知道该实现与某个接口对应。否则,我们将违反DIP原则。
因此,工厂模式非常适用于依赖注入。实际上,依赖注入容器只是一个自动化工厂,它从注释、配置文件等中提取信息,以能够创建应用程序实例并注入其依赖项。当然,它的依赖项也有依赖项,依此类推,如果你手动编写代码,它将变得很长,可能成为一个god对象。你可以通过定义工厂来解决这个问题,这将使代码更加简短明了,但某种程度上人们更喜欢自动化。
DataAccessContext context {get; set;}
public ChartFactory(DataAccessContext context) //Comes from DI
{
this.Context = context;
}
public Chart GetInstance(string type) // Factory instance
{
if(type == "Pie")
return new PieChart(context);
if(type == "Bar")
return new BarChart(context);
throw new ArgumentException("Invalid choice");
}