Design patterns DataContext应该存在多长时间？

我只是想知道DataContext应该能活多久。所有的模式和实践书籍，比如Dino Esposito的书，都告诉你，datacontext不能长久存在，也不应该被缓存。但正确的时间是多久？一个完整的web请求、一个工作单元、一个事务、一次只有一个查询？（我假设一个web请求通常不止一个工作单元）

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

---

有什么想法、评论、想法或批评吗

最简单的方法是尽快处理DataContext。也就是说，只要您愿意处理会引起头痛的问题，就可以随时保持数据上下文

与许多事情一样，答案是“视情况而定”，并且取决于具体情况。没有单一的答案

对于web应用程序来说，在web请求的生命周期中保持DataContext通常是很容易处理的

我建议您从较短的生命周期开始，然后在需要较长生命周期数据上下文的缓存和其他好处的情况下增加生命周期。

Alex James写道。他在信中指出，你需要考虑：

• 处置
• 建设成本
• 内存使用
• 线程安全
• 无国籍
• 自然有限寿命

---

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

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

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

应用程序_BeginRequest：授权创建数据上下文

应用程序请求：授权处理datacontext

我明智地选择使用单词authorize，因为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();
} 

---

在web应用程序中，但这在标准应用程序中如何工作？