Linq到SQL層/體系結構？

Question

我很抱歉我的問題可能會看到一箇舊的重複問題，但我正在開始Linq到SQL我想討論應該使用多少層（體系結構）？

我正在研究網絡上的大多數網站和小到中等規模的網絡應用程序。我明白將應用程序分爲多個層面有助於維護和增強，但坦率地說，我想要一些平衡的方式，這也給我快速的開發和代碼重用能力。我無法在這些不需要的圖層管理上花費太多時間。

在我使用4層（業務對象，BLL，DAL和用戶界面）之前，由於不同的人描述了不同的圖層，我對此產生了疑惑。請指導我使用什麼和多少層？謝謝

Answer 1

我決定爲小型項目使用一層（DAL + BLL），對於大型應用程序，我們將使用DAL & BLL的不同層。我將在DAL中使用Linq，並且funtiosn將返回IQueryable。

Answer 2

不要使用圖層體系結構。使用onion architecture。

Answer 3

從架構的角度來看最重要的方面是關注的分離。關注點分離導致乾淨的代碼，易於維護，可擴展的，等這就是說，我建議根據以下標準來決策的基礎：

• 嘗試構建您的系統以鬆散耦合的方式。因爲消息傳遞是可靠的，可伸縮的，異步的，鬆散耦合的等，所以使用消息傳遞而不是RPC。您可以使用MSMQ或NServiceBus（用於基於服務總線的體系結構）。
• 根據關注點分離創建圖層概念。對於例如您可以選擇僅具有UI層，業務邏輯層（業務規則+工作流）和數據訪問層或更細粒度（如UI層，服務層（外觀），業務邏輯層，數據訪問層）的典型3層架構，等等。使用IoC /依賴注入將使生活變得簡單，因爲沒有任何層會有直接的依賴性。此外，它促進了單元測試，因爲您注入模擬而不是單元測試的實際實現。有很多可用的IoC框架（NInject，Autofac，Castle Windsor，結構圖等等）
• 嘗試使用EF代替Linq到SQL，因爲後者僅適用於SQL，而EF可與任何數據庫。此外，在我看來，EF是微軟創新的地方，我認爲Linq to SQL可能會在一天內退休。

Answer 4

很好的問題haansi。這是我在建設中小型網站時經常遇到的問題。在創建一個能夠提供最大靈活性並支持快速部署的體系結構的過程中尋求這種平衡是我認爲我們都需要在所有工作中努力的結果。

就這麼說，我發現使用Repository Pattern對LINQ to SQL項目非常有幫助。我將它與Model View Presenter模式（用於WebForms或其他項目）結合在一起，它爲重複使用最小層提供了一個很好的基礎。

我的Webform調用一個Presenter類，它依次負責填充視圖。要填充該視圖，演示者可以調用N個存儲庫。 Repository是封裝你的DataContext類和你的LINQ to SQL調用的地方。這些調用返回模型類。

無論應用程序的規模如何，一個巨大的好處就是可以很好地重用您的存儲庫，您可以最大限度地使用LINQ，並且使用了其他軟件開發人員可以輕鬆讀取的一些模式，支持。

的另一大好處是，你現在已經創建了一個簡單的架構，可以使用單元測試的演示，測試回倉庫，但不會一噸的努力中獲益。

祝你好運！