DataContext 应该存在多长时间？

Question

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

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

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

Answer 1

最简单的做法是尽快处理掉 DataContext。也就是说，只要您愿意处理将导致的麻烦，您就可以将 DataContext 保留多久。

与许多事情一样，答案是“视情况而定”并且视情况而定。没有唯一的答案。

对于网络应用，在网络请求的整个生命周期内保留一个 DataContext 通常是非常简单的处理。

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

Answer 2

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

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

Answer 3

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

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

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

1. Application_BeginRequest：授权创建数据上下文。
2. Application_EndRequest：授权处置数据上下文。

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