asp.net - Entity Framework : Singletonish ObjectContext - Good, 不好，还是想太多？

Question

这个想法是创建一个公开上下文但处理它在 Web 应用程序中的存储的类。

目前这是我所拥有的:

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 文件中:

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

这个想法是，如果这是与 Web 应用程序一起运行的，则上下文会在第一次需要时创建(并保存到当前的 HttpContext)，并在请求结束时拆除。

如果这是一个 UnitTest 情况，则反对在第一次需要时创建并在 TestCleanup 中删除(在本文中不那么重要，但只是想澄清 _context 对象)。

现在，这背后的想法至少是不必这样做:

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

每次我想查询。我意识到这可能是我的懒惰，但我只是认为这样更容易、更干净:

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

并避免“使用”，在大多数情况下我都会尽量避免这种情况。最重要的是，我不会为每个回发创建 9001 个上下文。

现在我很好奇的是我是不是想多了？我应该继续为每个需要的方法创建一个上下文吗？在回帖中说我必须:

• 通过 ID 获取用户
• 根据 ID 获取网站
• 将网站添加到用户 (user.Site =foundSite)
• 保存用户

这可能需要至少 3 个上下文。 Entity Framework 是否足够智能，可以随时创建上下文？

Answer 1

您正在实现相当于 NHibernate 的每个请求 session 模式，这是 NHibernate 中的一个很好的构造。虽然我不能 100% 确定它适用于 EF，但很可能是这样。对其他 session 管理模式的进一步扩展是“每个业务 session 的 session ”，它允许 NHibernate 通过断开和重新连接 session 而不是销毁和创建 session 来在 HttpSession 的持续时间内延长 session 的保持时间。如果 EF 允许类似的功能而不是保持静态开放连接，您可以通过我的个人资料在我的博客上查看我如何使用 AOP 实现该模式。