Linq to SQL - 我應該如何管理數據庫請求？

我已經研究了一下DataContext的生命週期，試圖找出最好的辦法。Linq to SQL - 我應該如何管理數據庫請求？

鑑於我想在Web應用程序中重新使用我的DAL，我決定使用DataContext按業務對象請求的方法。

我的想法是從dbml文件擴展我的L2S實體以檢索信息，數據庫根據請求創建單獨的上下文，例如，

public partial class AnEntity 
{ 
    public IEnumerable<RelatedEntity> GetRelatedEntities() 
    { 
     using (var dc = new MyDataContext()) 
     { 
      return dc.RelatedEntities.Where(r => r.EntityID == this.ID); 
     } 
    } 
}

在返回實體方面......我需要在這一點上返回波蘇斯還是確定只返回業務對象從查詢返回？我明白，如果我嘗試訪問返回實體的屬性（在DataContext被處置後），它會失敗。然而，這就是我決定實施這些類型的方法的原因，例如

相反的：

AnEntity entity = null; 
using (var repo = new EntityRepo()) 
{ 
    entity = repo.GetEntity(12345); 
} 
var related = entity.RelatedEntities; // this would cause an exception

從理論上講，我應該能夠做到：

AnEntity entity = null; 
using (var repo = new EntityRepo()) 
{ 
    entity = repo.GetEntity(12345); 
} 
var related = entity.GetRelatedEntities();

考慮到我的特殊應用程序的情況下（需要在一個窗口服務& Web應用程序的工作），我想知道這是否似乎是一種合理的方法，是否存在明顯的缺陷，以及是否有更好的方法來解決我正在嘗試做的事情。

謝謝。

來源

2009-12-17 James

你想避免哪些線程相關的問題？ – Nate 2009-12-17 22:29:28

在這個線程詳細http://www.west-wind.com/weblog/posts/246222.aspx – James 2009-12-17 22:31:43

我從原來的帖子中刪除了這一行，因爲我不想受到太多的阻礙。但基本上我想避免任何衝突，如果我要在多線程環境中訪問我的DAL（如Web應用程序） – James 2009-12-17 22:35:50

一般而言，只要您不使用多個線程調用單個DataContext對象，您應該可以。換句話說，每個線程使用一個DataContext對象，並且不要在不同的DataContext對象之間共享數據或狀態。

其餘的多線程問題與數據庫中的concurrency有關，而不是線程操作。

除了這些警告之外，您的方法聽起來很合理。您可以使用部分類來實現業務方法，也可以在Linq to SQL類和存儲庫之間添加業務層。

來源

2009-12-17 22:39:41

在我的特定應用程序中，我不需要擔心併發性。我想或許一個好的業務層比擴展L2S實體更好。那麼就DataContext的用法而言，每個原子函數創建1個是相當可接受的？ – James 2009-12-18 08:49:46

這就是我所做的。每「一個工作單元」一個。 – 2009-12-18 16:17:00

你可以逃脫這樣的：

var repo = new EntityRepo(); 

entity = repo.GetEntity(12345); 

var related = entity.RelatedEntities;

爲什麼不處置的情況下不會導致連接泄漏或類似的東西的解釋請參見this StackOverflow post。

當由它們提取的實體超出範圍時（在請求結束時構建網站時），存儲庫和上下文將被垃圾收集器清理。

編輯：MSDN documents連接儘快打開並儘快關閉。因此，跳過使用不會導致連接池問題。

來源

2009-12-17 23:05:32

當GC運行時，沒有保證，因此通常更好的做法是將任何實現了IDisposable的對象封裝在using語句中。 – James 2009-12-18 08:50:33

Linq to SQL - 我應該如何管理數據庫請求？

回答

相關問題