實體框架：Singletonish ObjectContext - 好，壞，還是過度？

的想法是創建一個公開的上下文句柄，但它在Web應用程序的存儲類。實體框架：Singletonish ObjectContext - 好，壞，還是過度？

目前，這是我所：

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），並在請求結束時拆除。

如果這是一個單元測試的情況是對上首先需要創建，並在TestCleanup刪除（在此崗位作爲重要的，但只是想澄清_context對象）。

現在這背後的想法是，至少可以不必這樣做：

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

每次我想查詢。我知道這可能是我的懶惰，但我只是覺得它更容易和更清潔的有：

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

和「使用」，我儘量避免在大多數情況下可避免。最重要的是，我沒有爲每個回發創建9001個上下文。

現在我很好奇的是，我會在想這是什麼？我應該不斷爲每種需要的方法創建一個上下文嗎？說上一回後我必須：

從ID
獲取用戶從一個id
得到一個站點的站點添加到用戶（user.Site = foundSite）
保存用戶

這可能意味着至少3個上下文。實體框架是否足夠聰明，可以隨時保持創建上下文？

來源

2009-02-12 Programmin Tool

要實現每個請求的模式NHibernate的會議相當於是在NHibernate的一個較好的結構。雖然我不能肯定地說100％適用於EF，但它很可能是。其他會話管理模式的進一步擴大是每個商務會話的會話，讓NHibernate的延長斷開並重新連接會話，而不是破壞和創造緩繳一個HttpSession的持續時間的會話。如果EF允許類似的功能，而不是保持靜態的開放連接，你可以看看我是如何通過我的配置文件在我的博客上使用AOP實現該模式的。

來源

2009-02-12 18:54:53

我不知道這完全是一種模式，但是我之前和nHibernate一起工作過，並試圖對EF做同樣的事情。這基本上是我想要完成的。 – 2009-02-12 19:07:27

如果你想實現像NHibernate的與它的會話時，我認爲這是一個好主意，有這種模式。我確信在LinqToSql中，上下文對象的實現更像是一個入口點類，它充當了一個門面。我想認爲LinqToEntities是相似的。你可以有一個工廠實現來獲得一個datacontext到你的模型，你可以重新使用datacontext。如果你去單身人士的方式考慮單身人士對象的瓶頸，可用性和責任。

來源

2009-02-13 17:20:46 Perpetualcoder

檢查出this blog entry，它提供了關於爲實體框架上下文創建單例的更多詳細信息，以及爲什麼在ASP.NET中不起作用，並提出了一個類似於您的建議的解決方案。

來源

2009-05-26 11:35:02

實體框架：Singletonish ObjectContext - 好，壞，還是過度？

回答

相關問題