我只是想知道 DataContext 应该真正存在多久。Dino Esposito 的Microsoft .NET: Architecting Applications for the Enterprise等所有模式和实践书籍都告诉您，数据上下文不能长期存在，也不应该被缓存。但合适的时间是多久？一个完整的网络请求，一个工作单元，一个事务，一次只有一个查询？（我假设一个网络请求通常不止一个工作单元）
假设您将实体框架用作 Web 应用程序中的 ORM 工具。但是在这种情况下，身份映射模式又如何呢？假设您有一个 Customer DAL 的专用实例，它创建一个 Datacontext 和另一个 Invoice DAL，它自己也为此目的创建一个新的 DataContext。如果您已经获得了所有 DAL 的基类，那么它会创建 ObjectContext 的单个实例并在最后处理这个实例。这会被认为是一个糟糕的实施吗？在我看来，对于单个 Web 请求只有一个 ObjectContext 可能是有意义的。它可以利用实体框架支持的身份映射模式作为优势之一。
有任何想法、评论、想法或批评吗？
最简单的做法是尽快处置 DataContext。也就是说，只要您愿意处理将导致的头痛问题，您就可以将 DataContext 保留多久。
像许多事情一样，答案是“视情况而定”并且取决于情况。没有单一的答案。
对于 Web 应用程序，在 Web 请求的整个生命周期内保留一个 DataContext 通常是非常容易处理的。
我建议您从较小的生命周期开始，然后在需要缓存和更长生命周期 DataContext 的其他好处的情况下增加生命周期。
数据上下文的生命周期应该等同于应用程序中的一个工作单元。在 Web 应用程序中，这个工作单元与请求相关联。请求进来，服务器一口气处理它。在请求结束时，此请求所做的所有更改都会保存在数据库中。这是 Web 应用程序中的常见行为，其中大多数请求匹配单个用户操作。
因此，每个请求应该只有一个数据上下文。这不仅在工作单元模式方面有意义，而且在性能考虑方面也有意义。数据上下文是一个重量级的对象，构建起来很昂贵。第一级缓存的优势是所有 OR Mapping 工具通过其实现身份映射模式的必要性而开箱即用，进一步强调了仅使用一个数据上下文。
ASP.NET 在其应用程序和页面生命周期中有 2 个有助于实现的事件。
我明智地选择使用授权一词，因为 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();
}
亚历克斯詹姆斯写了一篇关于这个的好文章。在其中，他指出您需要考虑：