在我试图更新的这段旧代码中,他们是这样实现依赖注入的:
public class Program
{
private IProgramRepository programRepository;
public Program(IProgramRepository repository)
{
this.programRepository = repository;
}
public Program() : this(new EN_Program()) { }
现在在这个程序类中,所有的方法都是静态的,所以实际上所有的静态方法都像这样有两种方法:
public static List<Program> GetProgramsByUser(int userId)
{
return GetProgramsByUser(userId, GetDefaultRepository());
}
private static List<Program> GetProgramsByUser(int userId, IProgramRepository repo)
{
return repo.GetProgramsByUser(userId);
}
我已经阅读了关于实现DI的其他内容:
这根本不是依赖注入。这实际上明显违反了依赖倒置原则。该原则指出,“高级模块不应依赖低级模块,两者都应依赖抽象。详细信息应依赖于抽象”。在上面的代码中,Product.cs本身创建了EN_Program对象。因此,它直接依赖于IProgramRepository实现(EN_Program)。如果将来另一个IProgramRepository接口的实现出现,则Product.cs代码本身需要更改。所以可以证明这不是正确的方法。
看起来旧的开发人员想要实现DI,只从帮助类(Program.cs)开始,没有将任何东西注入到控制器中。
我是否正确地认为旧代码编写不正确?在实现DI时,是否有必要将从控制器到后端的所有内容都注入?
例如,控制器需要注入一个帮助类使用的接口(Program.cs)-然后将Program.cs注入一个存储库使用的接口
Program
实例时都提供依赖项(或始终通过 DI 容器获取Program
实例),则可以使用 服务定位器。如果您有许多类都依赖于某个存储库,则这是非常合理的;构造函数注入通过显式声明此依赖关系没有增加任何价值,因为它已经是一个明显的依赖关系。 - Masood Khaari