MVCS - 模型 - 視圖 - 控制器服務

我一直在使用MVC很長一段時間，聽到了「服務」層（例如Java的web項目），我一直在想，如果這是一個真正的建築模式鑑於我無法找到關於它的很多信息。MVCS - 模型 - 視圖 - 控制器服務

MVCS的想法是在控制器和模型之間有一個服務層，以封裝可能在控制器中的所有業務邏輯。這樣，控制器就在那裏轉發並控制執行。你可以在許多控制器（例如，一個網站和一個webservice）中調用一個服務，而不需要複製代碼。

2011-04-18 Matthieu Napoli

「我一直在想，如果這是一個真正的建築模式」 ......好，並不比其他設計模式或多或少真實:)這是所有關於選擇最有意義的抽象 - 在這種情況下，當您處理各種上游數據源（數據庫模型，其他Web服務等）時，MVCS似乎比MVC更有用的抽象，特別是當你開始考慮將你的工作作爲一項服務公開時。當我有一個後來公開爲REST API的Web應用程序時，該模式幫助我重新使用了大量代碼。 – Joe 2012-05-29 17:01:51

服務層可以有許多方法，但它通常是擁有核心業務處理邏輯的位置，並且位於您的MVC體系結構之下，但位於數據訪問體系結構的上方。

比如你一個完整的系統層可能看起來像這樣：

視圖層：你的MVC框架的選擇&代碼
服務層：您的控制器將調用這一層的對象，以獲取或更新模型或其他請求。
數據訪問對象：這些是您的服務層調用的獲取/更新所需數據的抽象。該層一般會或者調用數據庫或者其他系統（例如：LDAP服務器，Web服務，或的NoSql型DB）

服務層將被負責：

Retreiving和從各種數據源（或數據訪問對象）創建您的'模型'。
更新各個存儲庫/資源的值。
執行應用程序特定的邏輯和操作等

模型在你的MVC使用可能會或可能不會與您服務。您可能希望將服務提供給您的結果，並將它們操作爲更適合於您的媒介的模型（例如：網頁）。

來源

2011-06-02 14:37:17 Clinton

我通常使用外部訪問服務。雖然MVC將包含我所有的應用程序特定邏輯，但我會使用DBService或FacebookOAuthService之類的方法來處理其他系統的所有外部調用。或者封裝第三方庫而不是緊密集成，可以更容易地切換庫。對我來說，這對於像這樣的服務有很大的意義。 – Lex 2014-06-05 00:07:18

爲了補充說明，您的來自服務層的模型將更多地是數據傳輸對象，這可能會或可能不會直接轉化爲滿足視圖需求的東西。 – hanzolo 2017-07-20 16:53:51

沒有看到這個任何別的地方，搜查谷歌和發現任何參考我一直在思考這個模式我的你的問題在這裏:)

即使在今天，沒有太多的任何機構談論或公佈有關

視圖 - 控制器服務模式。

以爲讓你知道其他的都在思考同一個和上面的圖片是我認爲它應該如何。

目前我正在使用它在我現在正在處理的項目中。

我在模塊中使用上圖中的每個圖層以及它自己的自包含模塊。

該服務層是「連接器」，「中間人」，「服務器側控制器」，該「客戶端」側控制器做什麼爲客戶端，「服務」做爲服務器。

換言之，客戶端「控制器」只與「服務」即服務器端控制器「通話」。

控制器--->請求和接收從所述< -----服務層

服務層獲取或提供信息，以在需要它的服務器側的層。

服務本身並沒有做任何事情，只是連接服務器層和他們需要的東西。

下面是一個代碼示例：

來源

2016-11-25 17:20:06 Kbdavis07

我對這種體系結構的唯一擔憂是假設DataModel將具有與「View」的要求相同的「形狀」。如果它們是1對1或靠近它，那麼你可以在視圖中專門爲視圖設置一些屬性，但我認爲這很好，但是很多時候DataModel是從存儲角度設計的，並且ViewModel是根據觀點角度。 – hanzolo 2017-07-20 16:52:32

有「DataModels」和「ViewModels」，上面顯示的圖形很快完成，做得很差:) – Kbdavis07 2017-07-31 21:07:13

MVCS - 模型 - 視圖 - 控制器服務

回答

相關問題