Question

在我试图更新的旧代码中，他们实现了依赖注入：

public class Program
{
    private IProgramRepository programRepository;

     public Program(IProgramRepository repository)
        {
             this.programRepository = repository;
        }

     public Program() : this(new EN_Program()) { }

现在在这个程序类中所有的方法都是静态的，所以所有的静态方法实际上都有2个这样的方法：

    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 代码本身需要改变。所以它被探测到它不是正确的方式要做。

看起来旧的开发人员想要从帮助程序类（Program.cs）开始实现DI而没有注入控制器。

我是否认为这个旧代码编写不正确？实施DI时是否有必要从控制器到后端的所有内容都有注射？

离。控制器需要注入一个辅助类使用的接口（Program.cs） - 然后Program.cs注入一个存储库使用的接口

Answer 1

评论不正确。它讨论了依赖注入模式，但引用了Dependency Inversion Principle。重载构造函数是依赖注入模式的实现，默认构造函数是Poor Man's Dependency Injection anti-pattern的实现。

虽然重载的构造函数实现了依赖注入模式，但默认构造函数却没有并且确实违反了依赖性反转原则。由于引用的原因。

所以你绝对是练习依赖注入，但你也在练习穷人的依赖注入，这很多原因都很糟糕。例如：

您的代码直接依赖于低级别组件，不允许您单独发送它们。
直接依赖使交换实现变得更加困难，这是在添加横切关注点（使用装饰器或拦截器）时非常常见的事情。您不希望通过整个应用程序来更改所有构造函数，只是为了用装饰器或拦截器包装EN_Program实例。

Answer 2

第一种方法取决于工厂方法（我希望）。在此工厂方法中，将创建IProgramRepository。除了工厂方法本身之外，此功能不依赖于任何东西。

public static List<Program> GetProgramsByUser(int userId)
{
    return GetProgramsByUser(userId, GetDefaultRepository());
}

第二种方法也不依赖于其他类。依赖项在参数中“给定”。

private static List<Program> GetProgramsByUser(int userId, IProgramRepository repo)
{
    return repo.GetProgramsByUser(userId);
}

修改

官方Depenency Injection（DI）是控制反转（IoC）的一个子集，这些术语有时会混淆。 Perhapse官方认为你的代码并不真正遵循DI的规则，但肯定是IoC！

实现依赖注入静态方法

2 个答案: