服務層和ASP.NET MVC的目的2

Question

爲了理解MVC 2並試圖讓我的公司將它作爲未來開發的可行平臺，我近來一直在進行大量的閱讀。在過去的幾年裏，我一直非常專注於ASP.NET，我有一些工作要做。

目前，我瞭解存儲庫模式，模型，控制器，數據註釋等。但有一件事讓我無法完全理解並開始參考應用程序的工作。

第一個是服務層模式。我在這裏閱讀了很多關於Stack Overflow的博文和問題，但是我仍然不完全理解這種模式的目的。我觀看了高爾夫跟蹤器應用程序MVCCentral上的整個視頻系列，還查看了他發佈的演示代碼，它看起來像服務層只是另一個根本不執行任何工作的存儲庫模式的包裝。

我也讀過這篇文章：http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx它似乎有點回答我的問題，但是，如果您使用數據註釋來執行您的驗證，這似乎是不必要的。

我已經看過演示，帖子等，但我似乎無法找到任何簡單的解釋模式，並給我引人注目的證據使用它。

有人可以給我一個二年級（好的，也許是五年級）理由使用這種模式，如果我不這樣做，我會失去什麼，如果我這樣做，我會得到什麼？

Answer 1

在MVC模式中，您有責任在三個玩家之間分開：模型，視圖和控制器。

該模型負責執行業務內容，該視圖顯示業務結果（爲用戶提供業務輸入），而控制器的行爲類似於模型和視圖之間的粘合，將內部彼此的工作。

該模型通常由數據庫進行備份，因此您有一些DAO可以訪問該數據庫。你的業務做了一些......嗯......業務和存儲或從數據庫中檢索數據。

但誰來協調DAO？控制器？沒有！模型應該。

進入服務層。服務層將爲控制器提供高級服務，並將在幕後管理其他（低級別）播放器（DAO，其他服務等）。它包含您的應用程序的業務邏輯。

如果你不使用它會怎麼樣？

您必須將業務邏輯放在某個地方，受害者通常是控制器。

如果控制器是以網絡爲中心的，它將不得不接收它的輸入並提供響應作爲HTTP請求，響應。但是如果我想從一個與RPC或其他東西進行通信的Windows應用程序調用我的應用程序（並訪問它提供的業務）呢？然後怎樣呢？

那麼，你將不得不重寫控制器，並使邏輯客戶端不可知論者。但有了服務層，你已經有了。你不需要重寫東西。

服務層提供與未綁定到特定控制器實現的DTO的通信。如果控制器（不管是哪種類型的控制器）提供適當的數據（不管源），你的服務層將爲調用者提供服務，並隱藏調用者從事涉及的業務邏輯的所有責任。

Answer 2

我不得不說我同意上述dpb，包裝即服務層可重用，可嘲弄，我目前正在將這一層包含在我的應用程序中......這裏有一些問題/要求我正在思考（很快：p）可能會對你自己有所幫助...
1.需要許多不同用戶訪問的多個門戶（例如博客門戶，客戶門戶，內部門戶）。它們都必須是單獨的ASP.NET MVC應用程序（一個重要的要求）
2.在應用程序本身中，對數據庫的一些調用將類似，數據從存儲庫層處理的方法和方式。毫無疑問，來自每個模塊/門戶的一些控制器會對同一個調用進行完全或重載的版本，因此可能需要一個服務層（代碼到接口），然後我將在一個單獨的類項目中進行編譯。
3.如果我爲服務層創建單獨的類項目，則可能需要對數據層執行相同的操作，或將其與服務層結合使用，並使模型遠離Web項目本身。至少在我的項目增長的時候，我可以拋出數據訪問層（即LinqToSql - > NHibernate），或者團隊成員不需要處理任何其他項目中的任何代碼。缺點可能是他們可能吹的一切了大聲笑...