实体框架：ObjectContext的Singletonish

本文介绍了实体框架：ObjectContext的Singletonish - 好，坏得太多还是？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们的想法是创建一个公开上下文句柄，但它的存储在Web应用程序的类。

The idea is to create a class that exposes a context but handles the storage of it in a web application.

目前，这是我有：

public class EntityContext { private static String MAIN_CONTEXT_KEY = "MainContext"; private static TISQLEntities _context; public static void RemoveContext() { if ( HttpContext.Current != null && HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null ) { ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose(); HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null; } if (_context != null) { _context.Dispose(); _context = null; } } public static TISQLEntities Context { get { if (HttpContext.Current == null) { if (_context == null) { _context = new TISQLEntities(); } return _context; } if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null) { HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities(); } return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]; } } }

然后在Global.asax文件：

And then in the Global.asax file:

protected void Application_EndRequest(object sender, EventArgs e) { EntityContext.RemoveContext(); }

的想法是，如果这是正在与Web应用程序中运行，在上下文上首先需要创建（并保存到当前HttpContext）和推倒每当请求就结束了。

The idea is that if this is being run with a web application, the context is created on first need (and saved to the current HttpContext) and torn down whenever the request is over.

如果这是一个的UnitTest情况下，它是反对首先需要创建并在TestCleanup删除（在此岗位作为重要的，但只是想澄清_context对象）。

If this is a UnitTest situation it is against created on first need and removed in the TestCleanup (Not as important in this post but just wanted to clarify the _context object).

现在这背后的想法是在最不具备这样做：

Now the idea behind this is in the least to not have to do this:

using(TISQLEntities context = new TISQLEntities()) { .... }

每次我要查询。我知道这可能是我的懒惰，但我只是觉得它更容易和更清洁的有：

Everytime I want to query. I realize this may be me being lazy, but I just think that it's easier and cleaner to have:

EntityContext.Context.User.Select(...)

和避免用，我尽量避免在大多数情况下。最重要的是，我不是在每个回发创建9001环境。

And avoids "using" which I try to avoid for most cases. On top of that, I'm not creating 9001 contexts per postback.

现在我很好奇的是，我在我想这是什么？我应该不断为每一个需要一种方法上下文？说上一回后我有：

Now what I am curious about is that am I over thinking this? Should I just keep creating a context for every method that needs one? Say on a post back I have to:

• 从一个ID获取用户
• 从一个ID获得网站
• 的站点添加到用户（user.Site = foundSite）
• 保存用户

这可能意味着至少有3上下文。是足够聪明的实体框架，它的确定只保留创建上下文时？

That could entail at least 3 contexts. Is entity framework smart enough that it's ok to just keep creating contexts whenever?

推荐答案

您正在实现每个请求的模式NHibernate的会议相当于这是NHibernate的一个很好的结构。虽然我不能肯定地说100％，它是适用于EF最有可能是。其他会话管理模式的进一步扩大是每个业务对话​​的会议，让NHibernate的延长断开并重新连接会话，而不是破坏和创造缓缴一个HttpSession的持续时间的会话。如果EF允许，而不是让你可以看看我是如何实现AOP用在我的博客该模式通过我的个人资料一个静态的开放连接一个类似的能力。

You are implementing the equivalent of NHibernate's session per request pattern which is a good construct in NHibernate. While I can't say 100% for sure that it's applicable to EF it most likely is. Further expanding on other session management patterns is the Session per Business Conversation which allows NHibernate to extend holding a session over the duration of a HttpSession by disconnecting and reconnecting the session as opposed to destroying and creating. If the EF allows a similar ability as opposed to keeping a static open connection you could look at how I implemented that pattern using AOP on my blog through my profile.