0

我已經配置了我的IoC容器,團結解決我IDbContextEntityFramworkDbContext在我工作單位的構造。IoC容器應該解析OR映射器容器嗎?

我想知道如果這是最佳實踐,或者如果我只是在未來的頭痛未處置DbContext。這是一個ASP.Net MVC應用程序,所以會有很多短壽命容器。每個容器的使用期限爲每個請求

任何建議?

public class UnitOfWork : IUnitOfWork 
{ 
    private readonly IDbContext context; 

    public UnitOfWork(IDbContext context) 
    { 
     this.context = context; 
    } 
} 

public class SampleService : ISampleService 
{ 
    private readonly IUnitOfWork unitOfWork; 

    public SampleService(IUnitOfWork unitOfWork) 
    { 
     this.unitOfWork = unitOfWork; 
    } 
} 
+0

相關:http://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why – Steven

+0

您應該不會爲每個請求構建一個容器,因爲這會對性能產生嚴重的負面影響你的應用和配置的複雜性。儘管使用Unity的子容器功能很好,但通常仍然不需要,性能也很重要。 – Steven

+0

IoC容器不是通過請求,而是IoC容器構建一次,就好像在應用程序的生命週期中一樣。我的'DbContext'是每個請求,所以每個服務調用將只有一個IUnitOfWork,因此都是相同的DbContext。每個服務調用都被視爲單線程。 –

回答

1

由容器管理IDbContext並設置爲PerRequest生存期是最佳實踐。你的代碼看起來很乾淨,可以很容易地由IoC容器來管理。

As @Steven linked to,通常的做法是使用單位或工作並立即處置。

如果Unity IoC容器可以正確配置爲在請求結束時處理IDbContext,那最好。在某些情況下,您可能必須在Application_EndRequest()

1

中進行處理我認爲您的解決方案沒有問題,但在Unity文檔中存在關於使用每個請求生命期管理器的警告:Per Request Lifetime Management。我認爲,只要你知道你在做什麼,你就像使用那個一生的經理一樣。您可以使用的另一個選項是創建一個基本控制器並在該控制器上實現IDisposable。 MVC將在請求的最後調用控制器上的處理,以便您也可以處理任何對象。