我有一个小问题。对于无损架构，我使用依赖注入。 如何在我的其他类之间共享这个依赖解析器？这个解析器应该是一个带有一些实例的全局静态列表的静态类，还是我应该做这个非静态的并将这个解析器通过属性或构造函数传递给其他类？我认为，你应该做这个非静态的，因为如果你用一个单例静态解析器做这个，你就会依赖这个解析器。
【问题讨论】：
标签： c# architecture dependency-injection
你可以有两种类型的解析器。
使用构造函数解决依赖关系的地方，例如：
MyClass myClass;
public MyConstructor(MyClass myClass) {
this.myClass = myClass;
}
或者其他方法是使用setter方法使用setter注入，例如：
public void setMyClass(MyClass myClas) {
this.myClass = myClass;
}
还有其他设计模式，如工厂或单例，它们使用静态方法并根据输入参数生成不同的对象，您也可以使用它们，但它与 DI 完全不同，可以在 DI 中提供帮助。
【讨论】：
关于这一点已经说了很多，但普遍的共识是拥有一个全局“解析器”（又名Service Locator pattern）就是anti-pattern：
服务定位器的问题在于它隐藏了一个类' 依赖关系，导致运行时错误而不是编译时错误， 以及使代码更难维护，因为它 何时引入重大更改变得不清楚。
您应该使用相反的模式：依赖注入 (DI)，而不是使用这个全局解析器。与让类通过某些解析器请求依赖项相比，使用 DI 可以将依赖项注入到类中。最常见（通常也是最好）的方法是使用构造函数注入。这意味着某个类的构造函数将其所需的依赖项定义为类sole constructor中的构造函数参数。
类构造函数应该只包含该类直接使用的依赖项。类依赖项所需的依赖项不应暴露给该类，因为这只会不必要地增加代码的耦合，并使您的代码更难测试，更难推理。
这样做的结果是，您的应用程序中的所有类都不会负责构建和请求它们的依赖项。每个类都将这一职责推到调用链上，从而在应用程序中只有一个位置，靠近应用程序的启动路径，负责构建所有对象图：composition root。
组合根是您可以使用此类解析器的地方，但这是可选的。
【讨论】：