Question

我只是想知道DataContext应该存在多久。像Dino Esposito的Microsoft .NET: Architecting Applications for the Enterprise这样的所有模式和实践书都告诉你，datacontext不能长寿，也不应该缓存。但是合适的时间有多长？整个Web请求，工作单元，事务，一次只能查询一个？（我假设网络请求通常不仅仅是一个工作单元）

假设您将实体框架用作Web应用程序中的ORM工具。但是在这种情况下Identity Map Pattern呢？假设您有一个Customer DAL的专用实例，它创建了一个Datacontext和另一个Invoice DAL，它自己也为它的目的创建了一个新的DataContext。如果您已经为所有DAL获得了基类，那么会创建ObjectContext的单个实例并在最后处置它。这会被视为糟糕的实施吗？在我看来，对于单个Web请求只有一个ObjectContext是有意义的。它可以利用实体框架支持的Identity Map Pattern作为一个优势。

任何想法，评论，想法或批评？

Answer 1

最简单的事情是尽快处理DataContext。也就是说，只要您愿意处理将导致的麻烦，您就可以随时保留DataContext。

像许多事情一样，答案是“它取决于”并且取决于情况。没有一个答案。

对于网络应用，在网络请求的生命周期内保留一个DataContext通常很容易处理。

我建议你从小生命开始，然后在需要缓存和更长寿命DataContexts的其他好处的情况下延长生命周期。

Answer 2

亚历克斯詹姆斯写了a good article about this。在其中，他指出你需要考虑：

处置
建筑成本
内存使用
线程安全
无国籍
自然有限生命期

Answer 3

数据上下文的生命周期应该等于应用程序中的工作单元。在Web应用程序中，此工作单元与请求相关联。请求进来，服务器一次性处理它。在请求结束时，此请求所做的所有更改都会保留在数据库中。这是Web应用程序中的常见行为，其中大多数请求与单个用户操作匹配。

因此，每个请求应该只有一个数据上下文。这不仅在工作单元模式方面有意义，而且在性能方面也是如此。数据上下文是重量级对象，构造起来很昂贵。第一级缓存的优势在于所有OR映射工具通过实现身份映射模式的必要性而开箱即用，这进一步突出了仅使用一个数据上下文的优势。

ASP.NET在其应用程序和页面生命周期中有2个事件，便于实现。

Application_BeginRequest：授权创建datacontext。
Application_EndRequest：授权处理datacontext。

我选择使用这个词的授权的明智，因为Web应用程序不一定需要直接创建数据上下文它的自我，而是调用方法SessionFactory对象上，以实例化的数据上下文。

所有数据访问层对象或存储库都可以调用SessionFactory来获取当前数据上下文。

Global.asax的代码如下所示：


public static ISessionFactory SessionFactory { get; private set; }

void Application_Start(object sender, EventArgs e)
{
           SessionFactory = new SessionFactory();
}

void Application_BeginRequest(object sender, EventArgs e)
{
    var session = SessionFactory.OpenSession();
}

void Application_EndRequest(object sender, EventArgs e)
{
    SessionFactory.DisposeSession();
}

DataContext应该存在多长时间？

3 个答案: