c# - 使用 IOC Container 做 repository 层单例

Question

我公司的 MVC 解决方案使用 IOC 容器将缓存/存储库层注入(inject) Controller 。这是非常昂贵的，因为目前我们每次创建 Controller 时都会生成新类(由于缓存层对象具有对 repo 层的引用，因此可能会产生数千个对象——并且所有这些类都会被创建)。我知道 Singleton 模式由于多种原因(请参阅 Why Singletons are Evil)非常不受欢迎，但是有什么理由不将 IOC 容器设置为缓存/repo 层对象的单例？

谢谢。

Answer 1

你把事情搞混了。 Singleton 设计模式与 DI 库使用的 Singleton 生活方式完全不同。

使用单例模式，您通常会在一个具体类上定义一个 public static readonly 字段，该类包含该类的唯一实例；该实例由类本身创建，整个应用程序都可以访问该只读字段。例如:

public static class CarEngine
{
    public static readonly CarEngine Instance = new CarEngine();

    // class methods
}

通过单例生活方式，您可以指示容器在该容器的生命周期内只创建一个实例并重用它。

Singleton 设计模式是一个问题，因为它迫使消费者对具体类产生硬依赖(违反依赖倒置原则)，并且由于该具体类在内部控制创建，因此使用测试期间的虚假实现。除此之外，由于消费者没有需要该类作为依赖项的构造函数，因此有效地使依赖项对阅读代码、创建测试的人以及可以为您进行对象图分析的 DI 库的工具隐藏。 The article你指出的实际上确实在解释单例设计模式为什么不好方面做得非常好。

然而这篇文章从未真正提到单例生活方式，但由于它讨论了单例设计模式如何隐藏依赖项，这意味着应该注入(inject)依赖项。并且由于您希望某些类具有一个实例并通过构造函数注入(inject)它们，因此单例生活方式是解决此问题的实际方法。

Singleton 生活方式解决了这些问题，因为您从具体类中转移了创建单个实例的责任，这允许消费者依赖抽象而不是在他们的构造函数中，这使得依赖可见并且代码更可测试。

所以让你的注册单例没有错。事实上，我认为您应该尽可能多地注册单例，因为这可以防止开发人员在实践依赖注入(inject)时通常面临的大量问题。通过使每个组件不可变和无状态，它们变得更容易推理，并且您可以防止自己不小心将运行时数据注入(inject)组件，即 bad practice。 . DI 的另一个常见陷阱是 Captive Dependencies ，这意味着一个组件依赖于另一个应该有更短生命周期的组件。如果您使所有组件都成为不可变的、无状态的和单例的，那么俘虏依赖的问题就会消失，因为单例组件可以安全地相互依赖。

当然，您的组件中始终需要运行时数据(例如请求数据、O/RM 上下文等)，但这些可以在运行时通过注入(inject)提供程序或简单的 Func<DbContext> 来请求。进入从您的应用程序中抽象出第 3 方工具的适配器实现(如果您遵循 SOLID，这是一个很好的做法)。这个 Stackoverflow answer对此进行了更详细的介绍。