n層業務/服務層設計

Question

我試圖重新評估我們的n層結構，很想得到根據您的經驗提出了一些建議。這是我們典型的.NET n層（有時是n層）設計。

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

數據訪問通常由Entity Framework 4和Repository類。我試圖遵循Aggregate Root的概念，以避免擁有一個表格存儲庫，在我的經驗中說起來容易。我傾向於在儲存庫和表格之間有〜70％的匹配。

模型通常由我Entity Framework 4實體的，我一直在使用自追蹤EF實體成功。

業務是什麼，我掙扎之最。我通常每Repository有一個Manager類。這個類將包含像.Add（）這樣的方法，它將在轉發到repository.Add（）之前執行業務驗證。

服務，通常我只會實現這個如果事實上我期待建立一個基於Web服務的解決方案。這一層將負責封送DTO和實體之間的請求/響應。最重要的是提供更多的coarse grained接口。例如一個TradingService.SubmitTrade（），這實在是一個facade用於商業交易可能包括AccountManager.ValidateCash（），OrderManager.SubmitOrder（）等

參與討論
我的業務層是非常實體以實體爲中心，實際上它只是實體和存儲庫之間的粘合劑，兩者之間進行了驗證。我見過很多設計，其中服務層是對存儲庫的引用（實質上跳過「業務層」）。實質上，它與我的業務層具有相同的用途，但是它的確是有效的，但是它的責任（和命名）是一個更高層次，更粗糙的業務事務處理。使用上面的示例TradingService.submitTrade（）不會委託給任何業務經理類，它本身將查詢必要的存儲庫，執行所有驗證等。

我喜歡我的設計，因爲我可以重用業務但是我討厭這樣一個事實：對於每個存儲庫，我都有一個匹配的業務層管理器，從而創建大量額外的工作。也許該解決方案是業務層級別的不同類型的分組？例如，將諸如PhoneManager和EmailManager（注意我擁有電話實體和電子郵件實體）的單獨管理器類合併到ContactsManager等邏輯管理器類（請注意，我沒有「聯繫人」實體類型）。使用諸如ContactManager.GetPhones（）和ContactManager.GetEmail（）等方法。

我想比其他任何我想知道其他人如何組織和委派職責，無論他們有服務層，業務層，兩者等什麼持有ORM上下文引用等

Answer 1

我傾向於做你概述了附近的您的問題結束，並在業務層組的東西到管理者，使從商業的角度來看更符合邏輯的意義。

例如使用聯繫人，我肯定不會有PhoneManager或EmailManager。 「ContactsManager」對我來說是一個更有用的組合，只有少了很多經理才能完成同樣的事情。從商業角度來看，電話號碼和電子郵件只是一小段聯繫人。僅僅因爲他們擁有自己的表和實體並不意味着他們需要自己的經理。這並不意味着你不能重用它們。如果您需要在幾個地方使用電子郵件地址進行工作，ContactsManager可以有相關的方法。

我們在我們的環境中傾向於使用的是數據庫/實體層，然後是位於服務器上並處理業務規則和業務邏輯的業務層。該業務層通過WCF作爲服務公開給客戶端（或者至少與客戶端相關的東西是）。

這聽起來像你已經知道你想做什麼，所以我會建議做一些原型工作，看看它是如何工作的。 :)