实现依赖注入静态方法 [英] Implementing Dependency injection static methods

查看:109
本文介绍了实现依赖注入静态方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我尝试更新的旧代码中,他们实现了依赖项注入,如下所示:

In this old code I am trying to update , they implemented dependency injection like this:

public class Program
{
    private IProgramRepository programRepository;

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

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

现在在此程序类中,所有方法都是静态的,因此所有静态方法实际上都具有2个这样的方法:

now in this program class all methods are static, so all of the static methods all actually have 2 methods like this:

    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的其他内容:

Now I've read this among other things about implementing DI:

这根本不是依赖注入.这实际上显然违反了依赖反转原理.原则说高层次模块不应该依赖于低级模块,两者都应依赖在抽象上.细节应该取决于抽象."代码Product.cs本身创建EN_Program对象.所以直接取决于IProgramRepository实现(EN_Program).如果将来IProgramRepository接口的另一个实现来自Product.cs代码本身需要更改.因此,我们发现这是不正确的方法要做.

This is not dependency injection at all. This actually clearly violate the dependency inversion principle. The principle say that "High level module should not depend upon the low level module, both should depend on abstraction. Details should depends upon abstraction". In above code Product.cs itself create EN_Program object. So it directly depends on IProgramRepository implementation (EN_Program). If in future another implementation comes of IProgramRepository interface then Product.cs code itself need to change. So it is probed that it is not proper way to do.

看起来老的开发人员只是想从帮助器类(Program.cs)开始实现DI,而没有向控制器中注入任何东西.

It looks like the old developers wanted to implement DI just starting with the helper classes (Program.cs) with nothing injected into the controllers.

我是否可以正确假定旧代码编写不正确?在实施DI时是否有必要使从控制器到后端的所有东西都注入?

Am I correct in assuming that this old code was not written correctly ? Is it necessary when implementing DI that everything from the controller to the back end have injections?

例如控制器将需要注入助手类使用的接口(Program.cs)-然后,Program.cs将注入存储库使用的接口

ex. The controller would need to be injected with an Interface that the helper class uses (Program.cs) - then Program.cs is injected with an interface that the repository uses

推荐答案

注释不正确.它讨论了依赖注入模式,但引用了依赖反转原理.重载的构造函数是依赖注入模式的实现,默认构造函数是

The comment is incorrect. It talks about Dependency Injection pattern, but it quotes the Dependency Inversion Principle. The overloaded constructor is an implementation of the Dependency Injection pattern, and the default constructor is an implementation of the Poor Man's Dependency Injection anti-pattern.

尽管重载的构造函数会使用依赖关系注入"模式,但默认构造函数并未这样做,并且实际上违反了Dependency Inversion Principle .由于引用的原因.

Although the overloaded constructor practices the Dependency Injection pattern, the default constructor does not and does in fact violates the Dependency Inversion Principle. Because of the reasons quoted.

因此,您绝对在练习依赖注入,但是您也在练习穷人的依赖注入,这由于很多原因而很糟糕.例如:

So you're absolutely practicing Dependency Injection, but you are also practicing Poor Man's Dependency Injection which is bad for a lot of reasons. For instance:

  • 您的代码直接依赖于低级组件,因此您无法单独进行运输.
  • 直接依赖使交换实现变得更加困难,这在添加跨领域关注点(使用装饰器或拦截器)时非常常见.您不想浏览整个应用程序以更改所有构造函数,而只是用装饰器或拦截器包装 EN_Program 实例.

这篇关于实现依赖注入静态方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆