Linq到SQL和邏輯分區（DAL，BLL）

Question

我們將在.Net中重建我們的一個站點。我閱讀過許多文章，並且非常喜歡將我們的項目分離爲數據訪問層（DAL），業務邏輯層（BLL）和表示層（我們來自傳統ASP，因此這對我們來說是一個巨大的舉措） ）。我也很喜歡Linq to SQL。

由於Linq to SQL旨在快速開發，Linq to SQL有可能具有DAL，BLL和表示層嗎？使用Linq to SQL，DAL會返回可能在BLL中修改的實體或linq代碼？ DAL和BLL與Linq to SQL之間的關係似乎是一個沒有共識的模糊主題 - 因爲對於我們來說這是一個很大的跳躍，所以我絕對想在做任何事情之前有一個好的遊戲計劃。

鍵入數據集似乎更適合這個，但如果我能得到與Linq類似的東西，我會走這條路。

我想遠離nHibernate和其他第三方庫。

Answer 1

我們正在構建您所描述的內容，我們正在使用L2S來完成。一致認爲DAL和BLL之間的關係有點模糊，但我們有一個獨特的BLL和一個獨特的DAL。我們所有的邏輯都在BLL中，所有的數據檢索/修改都是通過調用DAL（使用LINQ調用）完成的。

我們的應用程序不使用任何類型的數據集。我們已經構建了實體類來表示我們的對象。現在我已經花了幾個月的時間來構建其中的一部分，我沒有看到我們（我）會回到數據集。

此外，我不會掛在L2S上「瞄準快速發展」。這使得它聽起來像一個原型工具。我們發現它是一種工業強度工具。這可能與微軟現在可能對此提出的意見相反，因爲他們寧可使用EF。

蘭迪

Answer 2

我建議退一步再看看您的要求。

您是否需要真正的3層（即物理部署到不同的機器）還是隻需要邏輯分區？

我在我寫的第一個大應用程序中犯了這個錯誤。我從不需要物理3層（並且永遠不會需要），但是這樣設計應用程序。最顯着的後果是我Linq2Sql不支持斷開實體上的更改跟蹤。我用Linq2Sql Entity Base來解決這個限制，但是它非常糟糕地違反了持久性無知的概念（後來人們總是會更好地知道，呵呵？）。

對於應用程序體系結構，實際的n層應用程序有很多其他含義。

您將需要消息傳遞，數據傳輸對象等Linq2SQL是一個體面的ORM，與LINQ的緊密集成提供了獨特的可能性。其他ORM仍然需要一些時間趕上這裏。 NHibernate 3.0是隧道盡頭的燈光。 如果您有簡單的數據模型並且可以按照「每個表的類別」方式映射，Linq2SQL是一個很好的ORM。

對於斷開連接的變更跟蹤（如果進入n層，您將需要），其他ORM具有更好的支持。

，最後：

（我們從傳統的ASP來得那麼這 對我們是一個巨大的一步）

在這種情況下，我會特別小心。交換技術往往被低估。即使團隊中最聰明的程序員也會做出錯誤的決定，因爲他們缺乏技術經驗。儘管如此，重要的是要採用新的方式並改善你的技能。那些永不失敗的人永遠不會成功。

Answer 3

恕我直言，LINQ to SQL是目前最好的選擇。它確實使數據的工作變得無痛苦，而且幾乎很有趣。 :-)如果你對LINQ to SQL感興趣，我會看看我們的PLINQO項目。它對LINQ to SQL有一些很大的增強，使它成爲一個更好的整體解決方案。

Answer 4

我會說L2S 是的DAL。單獨類中的L2S +業務邏輯變成合並的DAL + BLL，DAL側是L2S運行時，以及L2S生成的代碼（數據上下文，實體類等）。

您仍然可以很容易地將它們分開，以便L2S生成的部分以及對實體和datacontext的任何擴展都位於單獨的DLL中，並在獨立的dll/service/etc中提供額外的業務邏輯。但是在很多情況下，沒有必要將它們分開。

當使用L2S時，分離爲DAL + BLL的一個原因是，如果您預見到您將轉向另一種數據訪問技術，或者您可能正在使用多種數據訪問技術。將單獨的DAL與任何特定於L2S的內容分開，可以更輕鬆地切換DAL。如果你想分離DAL + BLL出於這個原因，L2S DAL-DLL應該公開實體類，任何派生類或投影類，以及獲取實體或集合（List等）的方法，但保持DataContext內部爲DAL以避免讓L2S特定的事情（L2S查詢等）慢慢進入BLL。

JMHO。

---

因爲別人提到L2S工具，這裏是一個什麼時候會再有一個更完整的總結：http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

我想使用LINQ的DAL和BLL概念不再有意義。因此，我在代碼（父）文件夾下的「域」文件夾下放置了linq類和 一些getters &設置器。然後我創建了'Repository'類和'FontEnd'類。