將LINQ上下文作爲請求變量存儲或不存儲？

這是在一個http請求期間使用LINQ上下文的好方法嗎？幾乎在每個請求中，我都有一些來自數據庫的選擇和一些插入/更新。它接近工作，但我不知道如何在服務器和負載均衡的服務器上產生大量流量，任何人都有關於在請求的整個生命週期內保持Context的任何意見/想法？將LINQ上下文作爲請求變量存儲或不存儲？

public static AccountingDataContext Accounting 
{ 
    get 
    { 
     if (!HttpContext.Current.Items.Contains("AccountingDataContext")) 
     { 
      HttpContext.Current.Items.Add("AccountingDataContext", new AccountingDataContext(ConfigurationManager.ConnectionStrings["SQLServer.Accounting"].ConnectionString)); 
     } 
     return HttpContext.Current.Items["AccountingDataContext"] as AccountingDataContext; 
    } 
}

來源

2011-07-19 Andreas

我使用Unity的依賴注入，但這個想法是一樣的：

protected void Application_BeginRequest() { 
    var childContainer = this.Container.CreateChildContainer(); 
    HttpContext.Current.Items["container"] = childContainer; 
    this.ControllerFactory.RegisterTypes(childContainer); 
} 

protected void Application_EndRequest() { 
    var container = HttpContext.Current.Items["container"] as IUnityContainer; 

    if (container != null) { 
     container.Dispose(); 
    } 
}

的容器是負責建立了一些事情，其中之一就是數據上下文。奇蹟般有效。我沒有做過負載平衡，但無法想象你會遇到那裏的問題。請求獲取自己的上下文，該上下文封裝了連接到數據庫的單個用戶。使用舊式ADO .NET進行數據訪問沒有什麼不同。

來源

2011-07-19 18:38:57 Yuck

這在一些層面上是一個好主意。但是您可能想要從Begin_Request事件推回實例化。使用集成管道，您將爲您的站點的每個請求初始化一個相當昂貴的DB上下文。包括favicon.ico，所有樣式表和所有圖片。

最好的，簡單的實現東西，只有當事情要求的上下文實例化是Ayende's example for NHibernate's ISession;你可以用適當的位替換它來實例化你的L2S上下文。

來源

2011-07-19 18:47:52

將LINQ上下文作爲請求變量存儲或不存儲？

回答

相關問題