DataContext 应该存活多久？

发布于 2024-08-16 12:37:09 字数 796 浏览 9 评论 0原文

我只是想知道 DataContext 到底应该存在多久。所有模式和实践书籍，例如 Dino Esposito 的 Microsoft .NET：为企业构建应用程序告诉你，datacontext 不能存活太久，也不应该被缓存。但多久才是合适的时间呢？一个完整的 Web 请求、一个工作单元、一个事务、一次只有一个查询？（我假设一个 Web 请求通常不止一个工作单元）

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

迷雾森÷林ヴ 2024-08-23 12:37:09

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

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

对于 Web 应用程序，在 Web 请求的生命周期中保留 DataContext 通常非常容易处理。

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

回复收藏 0 原文

遗心遗梦遗幸福 2024-08-23 12:37:09

Alex James 写道一篇关于此的好文章。在其中，他指出您需要考虑：

处置
构造
成本内存使用
线程安全
无状态
自然有限生命周期

回复收藏 0 原文

养猫人 2024-08-23 12:37:09

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

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

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

Application_BeginRequest：授权创建数据上下文。
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();
}

The lifetime of a data context should be equivalent to a unit of work in the application. In web applications this unit of work correlates with a request. The request comes in and the server processes it in one go. At the end of the request all changes made by this request get persisted in the database. That is the usual behaviour in a web application, where most of the requests match a single user action.

Therefore there should only be one data context per request. This makes sense not only in terms of the unit of work pattern, but also in respect to performance considerations. A data context is a heavyweight object, that is expensive to construct. The advantage of the first level cache, that comes out of the box with all OR Mapping tools through their implementation of the Identity Map Pattern necessity, underlines the use of only one data context even further.

ASP.NET has 2 events in their application and page life cycle that facilitates the implementation.

Application_BeginRequest: Authorise the creation of the datacontext.
Application_EndRequest: Authorise the dispose of the datacontext.

I choose the use of the word authorise wisely, since the web application doesn't necessarily need to create the data context it self directly, but rather call a method on a SessionFactory object to instanciate the data context.

All Data Access Layer objects or repositories can than call the SessionFactory to obtain the current data context.

The code for Global.asax looks like this:


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();
}

回复收藏 0 原文

~没有更多了~