【问题标题】:Singleton injecting a class which persists for the lifetime of the request单例注入一个在请求的生命周期内持续存在的类
【发布时间】:2017-01-25 14:58:43
【问题描述】:

我有一个包含以下类的 ASP.NET Web 应用程序:

public class AppContext : IAppContext {
    private readonly IDataContext _dataContext;

    public AppContext(IDataContext dataContext) {
        _dataContext = dataContext;
    }

    ...
}

public class DataContext : IDataContext {
    ...
}

这些是使用 Unity 注册的,如下所示:

container.RegisterType<IAppContext, AppContext>(new ContainerControlledLifetimeManager());
container.RegisterType<IDataContext, DataContext>(new PerRequestLifetimeManager());

AppContext 是一个单例并且在应用程序的生命周期中存在,但 DataContext 仅在当前请求的生命周期中存在。

但是,由于 DataContext 是在 AppContext 类的构造函数中注入的,因此它将在请求之间持久化。这会导致问题,因为 DataContext 在请求结束后被释放。如何在 AppContext 类中注入 DataContext 以便检索正确的实例?

【问题讨论】:

  • 如果AppContext 有一个公共构造函数,它如何是一个signelton?
  • 您遇到的问题是一个常见的陷阱,通常称为Captive Dependency
  • @ZoharPeled OP 不是在谈论Singleton Design Pattern,而是在谈论单身生活方式,这是一个常见的术语在谈到依赖注入和 IoC 容器时。
  • @Steven 谢谢,我不知道 Singleton Liststyle。
  • 感谢@Steven,虽然它至少没有修复程序,但这给了我解决问题的线索。

标签: c# asp.net dependency-injection unity-container


【解决方案1】:

这意味着 AppContext 的整个设计是无效的,它应该根据请求存在,因为它现在取决于一些实际的请求数据上下文。

作为解决方案,将其拆分为包含共享逻辑的单例类和具有依赖于数据上下文和共享逻辑的逻辑的类。

public class SingletonAppContext : ISingletonAppContext //as singleton
{
    //Source code where no data context needed
}

public class RequestAppContext : IRequestAppContext
{
    public RequestAppContext(ISingletonAppContext appContext, IDataContext dataContext)
    {
    }

    //Source code where data context is needed
}

【讨论】:

  • 越想越喜欢这个想法。我将把它标记为答案,但也值得阅读@Steven 指出的Captive Dependency 文章。
猜你喜欢
  • 2016-07-12
  • 2023-03-11
  • 2016-12-01
  • 2018-06-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-06-16
  • 1970-01-01
相关资源
最近更新 更多