IoC 容器是否应该解析 OR Mapper 容器？答案

【问题标题】：Should the IoC container resolve the OR Mapper container?IoC 容器是否应该解析 OR Mapper 容器？
【发布时间】：2014-02-28 22:25:36
【问题描述】：

我已配置我的 IoC 容器 Unity 以在我的工作单元的构造函数中解析我的 IDbContext 和 EntityFramwork DbContext。

我想知道这是否是最佳实践，或者我是否只是在为未处置的 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;
    }
}

【问题讨论】：

相关：stackoverflow.com/questions/10585478/…
你当然不应该为每个请求构建一个容器，因为这会对你的应用程序的性能和配置的复杂性产生严重的负面影响。使用 Unity 的子容器功能很好，尽管通常仍然不需要并且性能很重。
IoC 容器不是按请求构建的，IoC 容器是一次构建的，就好像应用程序的生命周期一样。我的DbContext 是每个请求，所以每个服务调用将只有一个 IUnitOfWork，所以所有相同的 DbContext。每个服务调用都被视为单线程。

标签： entity-framework orm inversion-of-control unity-container

【解决方案1】：

让 IDbContext 由容器管理，并设置为 PerRequest 生命周期是最佳实践。您的代码看起来很干净，可以很容易地由 IoC 容器管理。

作为@Steven linked to，通常的做法是使用单位或工作并立即处理。

如果可以正确配置 Unity IoC 容器以在请求结束时处理 IDbContext，则最好。在某些使用 ASP.NET 的情况下，您可能必须在 Application_EndRequest() 中进行处理

【讨论】：

【解决方案2】：

我认为您的解决方案很好，尽管 Unity 文档中关于使用每个请求生命周期管理器的警告：Per Request Lifetime Management。我认为，只要您知道自己在做什么，您就可以按照预期使用该生命周期管理器。您可以使用的另一个选项是创建一个基本控制器并在该控制器上实现 IDisposable。 MVC 将在请求结束时调用控制器上的 dispose，因此您也可以通过这种方式处理任何对象。

【讨论】：