一般N層體系結構問題

在一個N層應用程序中，你應該有一個業務邏輯層和一個數據訪問層。簡單地有兩個程序集：BusinessLogicLayer.dll和DataAccessLayer.dll來處理所有這些邏輯是不是很糟糕？你如何真正代表這些圖層。看起來很傻，有一個BusinessLogic類庫包含像CustomerBusinessLogic.cs，OrderBusinessLogic.cs等類，每個類調用它們在DataAccessLayer類庫中相應命名的表親，即CustomerDataAccess.cs，OrderDataAccess的.cs。一般N層體系結構問題

我想創建一個使用MVP的Web應用程序，它看起來並不像這樣被切割和乾燥。關於業務邏輯應該放在MVP中的位置有很多意見，我不確定我是否找到了非常好的答案。

我希望這個項目很容易測試，我儘可能的堅持TDD方法論。我打算使用MSTest和Rhino Mocks進行測試。

我在想的東西像我的架構如下：

我會使用LINQ到SQL交談的數據庫。 WCF服務爲業務邏輯層定義數據合約接口。然後將MVP與ASP.NET Forms一起用於UI/BLL。

現在，這不是這個項目的開始，大部分LINQ的東西已經完成了，所以它被卡住了。 WCF服務將取代現有的DataAccessLayer程序集，UI/BLL將取代BusinessLogicLayer程序集等。

這種情況在我的腦海中是有道理的，但它確實很晚。任何沿着這條路走過的人都有任何指導？良好的聯繫？警告？

謝謝！

來源

2010-03-19 mikesigs

我已經看到了它的樣子，有含類像 BusinessLogic類庫： CustomerBusinessLogic.cs， OrderBusinessLogic.cs等

哎喲。獲取並閱讀Scott Ambler的「構建可以工作的對象應用程序」。你的方法不是，而且是維護強光 - 沒有任何物體。

我會使用LINQ-To-SQL與數據庫進行通信。 WCF服務來定義數據業務合同接口邏輯層。然後使用MVP和ASP.NET 用於UI/BLL的表單。

是。讓應用程序人爲地變得更加複雜和慢的好方法。拋出完整的WCF服務 - 它們的用途是什麼？ WCF用於SOA，並且SOA駐留在用戶界面中（即，它是用於其他應用程序的信任boudary和用戶界面）。除非你有這個要求....引入額外的慢技術只是有開銷，這是愚蠢的。

WCF服務將取代現有的裝配DataAccessLayer

每日跆拳道 - 你到底你有沒有當您使用LINQ to SQL的一個DAL組件？ LINQ to SQL（運行時）是您的DAL。

任何人走過這條路有任何指導？良好的聯繫？

你基本上選擇了我能想到的每個反模式 - 維護噩夢，過度設計了大量無用的技術。您將圖層技術強制爲分層架構。

閱讀我提到的這本書。

來源

2010-03-19 06:15:23 TomTom

謝謝湯姆湯姆，無視我的職位，而不是我的計劃。我會拿起你提到的那本書的副本。 – 2010-03-19 06:23:58

謝謝你的回答。這有點嚴厲，但我認爲它是一個跡象，表明你有如此強烈的感情。但請注意，這不是我的設計。我在想WCF將是一個好方法。這似乎是合適的，但你是對的，這會增加不必要的開銷。要回答您的「每日WTF」，我們有一個包含我們的實體的LINQ程序集，並且DAL包含我們的LINQ層的API。但是，很多BLL邏輯似乎只是調用DAL的存根。這些層可能會合併成一個單一的服務層（因此我想到了WCF）*嘆息* – mikesigs 2010-03-19 13:16:26

答案是誠實和正確的，答案中的任何苛刻似乎都是有保證的。爲什麼它需要使用通信渠道？爲什麼你的業務邏輯不在你的模型對象中？當它應該是你的透明持久域模型時，爲什麼你要堅持把LINQ to SQL稱爲「DAL」？這裏面有太多的東西，只要有人知道，大部分都沒有理由，這一切在你的腦海中可能是有道理的，但我無法理解爲什麼你想要處理所有那些東西。 – yfeldblum 2010-03-21 02:55:35

關於XXXBusinessLogic，他們很快就變成了God Objects。思考代表行爲的域中有意義的對象，而不是在BusinessLogic「對象」中。這些「對象」將結束執行XXX的所有工作，是的，它們是維護的噩夢。

來源

2010-03-21 02:27:42 bloparod

一般N層體系結構問題

回答

相關問題