服務層是否可以包含多個服務？

Question

我正在重新構建一個大型Web表單ASP.Net應用程序，插入一個服務層以從表示層中帶走不需要的責任。

我見過的，所有的服務方法都包含在一個類中的很多例子。

這是常見/最佳做法嗎？或者在服務層中有多個服務類是完全可行的？我傾向於擁有多項服務，並且這些服務可以互相交流。

任何指導，優點/缺點？

Richard

P.請注意，我並不是在討論服務層，WCF或其他服務，儘管這可能會在以後變得更相關。

Answer 1

的SOLID principles，特別是Single Responsibility Principle會建議讓所有的在一個對象的功能，是一個壞主意，我傾向於同意。隨着應用程序的增長，單個課程將變得難以維護。

您對Yuriys的回答的建議會提示您想要使用IOC容器。讓我們考慮，在片刻詳細...

的更多的功能，這個單一類包含，越依賴這將需要。你最終可能會得到一個具有很長參數列表的服務的構造函數，只是因爲這個類涵蓋了很多基礎，並且依賴於較低級別的其他功能，例如日誌記錄，數據庫通信，身份驗證等。可以說該服務的使用者想要在銷燬該實例之前調用該類的一個特定方法。您的IOC容器需要注入該服務在運行時可能「需要」的每個依賴項，即使消費者只會使用1或2個這些依賴項。

而且從操作的角度來看 - 如果你對團隊同時服務層上工作的一個以上的開發，有合併衝突的可能性越大，如果你都編輯一個文件。但是，如建議您可以使用partials來解決這個問題。

通常實用性旁邊一個衆所周知的模式或原則的劑量是前進的最佳途徑。

如果您還沒有，我建議您研究Service Orientated Architecture，因爲它可以幫助您回答解決方案中的一些關鍵決策。

Answer 2

當然，它可以。另外，我相信最好從這個上帝服務層類中提取幾個接口的功能（即ISecurityService，INotificationService等），並在不同的項目中實現每個接口。另外，你可以利用一些IOC容器來解析實現服務接口的類。這樣，您可以獨立更改每個服務的實現，而無需更改客戶端功能。

至少，在第一時間，你可以標記您的服務超類的部分，然後分裂它通過功能集成到少數的.cs（的.vb）在Visual Studio中有意義的名字，並把它們組合在一起的文件。這將簡化跨服務方法的導航。

Answer 3

我拿上構建的應用程序將與所述應用拆分成兩個項目AppX.Web（UI邏輯）和AppX.Business（業務邏輯）啓動，但仍然讓他們在相同的VS解決方案。業務邏輯和用戶界面邏輯之間的結構闡明可以幫助您瞭解在多個網頁之間共享哪些服務，以及哪些服務位於singel網頁的本地。您應該避免直接在網頁之間重複使用代碼，如果您發現這是必要的，那麼您應該將這段共享代碼移動到業務邏輯層。

在實現業務邏輯的項目，你應該嘗試爲不同類型的業務邏輯創建單獨的類。這些課程當然可以與海誓山盟對話，但是避免讓網頁與對方聊天。

一旦你已經從業務邏輯，你可以繼續在必要時打破AppX.Business碼成小塊分開的UI邏輯。常見的例子包括：

• AppX.Data：一個數據訪問層（DAL），其從實際的業務邏輯
• AppX.Dto隔離所有數據操作：數據傳輸對象（DTO），其可以在許多有用情景，例如的jQuery
• AppX.Common將數據發送到客戶端瀏覽器進行處理：共享邏輯是通用的許多其他應用程序，這可能是你以前創建的輔助類或事情應該在項目結束後納入公司進行審查廣泛的支持課程。

最後，我們來討論一下全局性，並將您的業務邏輯公開爲WCF服務。在那種情況下，你實際上不需要改變現有結構中的任何東西。您可以將WCF服務添加到現有的AppX.Web項目中，也可以在AppX.Service中單獨公開它們。如果您已將業務邏輯從UI邏輯中正確分離出來，那麼WCF層可以僅僅是業務邏輯的簡單包裝。

在實現WCF服務是完全可能做到這一切在一個類中。 WCF服務中沒有真正的業務邏輯可用，因爲它只是直接調用業務邏輯。

如果你建立一個新的應用程序，你應該考慮你的整體設計在前面，但現在你正在重新構建，我認爲你應該努力一步一步：通過創建AppX.Web

• 開始， AppX.Business項目
• 識別服務，創造班AppX.Business這些服務從AppX.Web項目
• 移動代碼到AppX.Business新的類，並確保您從Web項目給他們打電話。
• 如果您覺得需要這樣做，請繼續進行額外的分解！