实体框架:Singletonish ObjectContext - Good,Bad还是Overthinking？

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个上下文.实体框架是否足够智能,可以随时继续创建上下文？

Answer 1

您正在为每个请求模式实现相当于NHibernate的会话,这是NHibernate中的一个很好的构造.虽然我不能说100%肯定它适用于EF它很可能是.进一步扩展其他会话管理模式的是每个业务对话​​的会话,它允许NHibernate通过断开和重新连接会话而不是销毁和创建来延长在HttpSession持续时间内持有会话.如果EF允许类似的能力而不是保持静态打开连接,那么您可以通过我的个人资料查看我在博客上使用AOP实现该模式的方式.