c# - 构造函数 + 依赖注入(inject)

标签 c# oop dependency-injection

如果我正在编写一个具有多个构造函数参数的类,例如:

class A{
    public A(Dependency1 d1, Dependency2 d2, ...){}
}

我通常会创建一个“参数持有者”类型的类,例如:

class AArgs{
    public Dependency1 d1 { get; private set; }
    public Dependency2 d2 { get; private set; }
    ...
}

然后:

class A{
    public A(AArgs args){}
}

通常,使用 DI 容器我可以为依赖项配置构造函数并解决它们,因此当构造函数需要更改时影响最小。

这是否被视为反模式和/或反对这样做的任何论点?

最佳答案

这确实为您的依赖项似乎是可选打开了大门。通过为 AArgs 类的每个依赖项提供属性,有人会认为他们只需要填写 Dependency1,一切都会按预期工作。

通过显式单独列出所有依赖项,您可以清楚地了解类运行所需的条件。如果你有太多的依赖关系以至于构造函数很麻烦,那应该被认为是一种气味,因为你的类可能做的太多了。

关于c# - 构造函数 + 依赖注入(inject),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2549173/

相关文章:

java - 嵌套开关还是多功能,什么才是更好的设计?

c# - Azure 函数中键入的 HTTP 客户端未正确注册

asp.net-core - 在没有 BuildServiceProvider() 的情况下为 ConfigureApplicationCookie 设置自定义 SessionStore

c# - 循环依赖树,合理与否

c# - Azure - 无法在现有服务计划上创建新的 Web 应用程序

c# - 为什么子类变量先于父类成员变量初始化

c# - 从不安全的结构中获取固定的数组值

php - 面向对象设计 : Is it good to restrict I/O parameters?

c# - 强制窗口在打开时获得焦点

python - 将实例转换为其类的子类型(为类方法调用 super)