2017-01-25 36 views
1

我有以下類的ASP.NET web應用程序的生命週期的類:辛格爾頓注入其中持續該請求

public class AppContext : IAppContext { 
    private readonly IDataContext _dataContext; 

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

    ... 
} 

public class DataContext : IDataContext { 
    ... 
} 

這些是使用Untity像這樣註冊:

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

AppContext是一個單例,並且在應用程序的整個生命週期中都存在,但DataContext只在當前請求的整個生命週期內存在。

然而,由於在DataContext是AppContext類將跨請求持久化的構造函數中注入。這會導致問題,因爲DataContext在請求結束後處理。我怎麼能在AppContext類中注入DataContext,以便我可以檢索正確的實例?

+2

如果'AppContext'是一個signelton,如果它有一個公共構造函數? –

+1

您所遇到的問題是一個常見的陷阱,通常被稱爲[圈養依賴](http://blog.ploeh.dk/2014/06/02/captive-dependency/)。 – Steven

+1

@ZoharPeled OP是*** ***不談論[Singleton設計模式](https://en.wikipedia.org/wiki/Singleton_pattern),但關於**的Singleton生活方式**這是一個常見的術語,當談論依賴注入和IoC容器。 – Steven

回答

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 
} 
+0

我越想越想越喜歡這個想法。我打算將其標記爲答案,但也值得閱讀@Steven指出的[Captive Dependency](俘虜依賴)(http://blog.ploeh.dk/2014/06/02/captive-dependency/)文章。 – nfplee