5

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

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 代码本身需要更改。因此，它被认为是不正确的做法。

看起来老开发人员只想从辅助类 (Program.cs) 开始实现 DI，而没有向控制器注入任何内容。

假设这个旧代码没有正确编写，我是否正确？在实现 DI 时是否有必要从控制器到后端的所有内容都进行注入？

前任。控制器需要注入帮助类使用的接口 (Program.cs) - 然后 Program.cs 注入存储库使用的接口

4

2 回答 2

7

评论不正确。它谈到了依赖注入模式，但它引用了依赖倒置原则。重载的构造函数是依赖注入模式的实现，默认构造函数是穷人依赖注入反模式的实现。

尽管重载的构造函数实践了依赖注入模式，但默认构造函数并没有而且实际上违反了依赖倒置原则。由于引用的原因。

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

  • 您的代码直接依赖于低级组件，不允许您单独发布它们。
  • 直接依赖使得交换实现变得更加困难，这在添加横切关注点（使用装饰器或拦截器）时很常见。您不想通过整个应用程序来更改所有构造函数，只是为了EN_Program用装饰器或拦截器包装实例。
于 2013-04-29T15:43:56.180 回答
1

第一种方法取决于工厂方法（我希望如此）。在这个工厂方法IProgramRepository中创建了一个。这个函数不依赖于任何东西，只依赖于工厂方法本身。

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

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

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

编辑

正式的依赖注入 (DI) 是控制反转 (IoC) 的一个子集，这些术语有时会混淆。也许正式你的代码并没有真正遵循 DI 的规则，但它肯定是 IoC！

于 2013-04-29T15:23:09.553 回答