爲什麼在服務器上使用MVC？這不是客戶端模式嗎？

Question

我正在嘗試學習web開發。我主要了解MVC的概念，但我爲什麼在服務器端使用MVC模型感到困惑......就像Spring MVC一樣。服務器端不是模型和服務，然後是客戶端服務，視圖和控制器（AngularJS甚至在客戶端顯式）？

我真的很擔心MVC模型如何適應或促進服務器端開發。

Answer 1

MVC不僅僅是Web應用程序所使用的模式。任何具有UI的應用程序都可以使用MVC模式。

這個想法是，你有一個視圖（HTML，或在你的操作系統，甚至是一個報告或一些窗口），你有一個模型，表示該視圖的動態部分。然後你有一個專門處理輸入和執行「業務邏輯」來生成模型並將其應用於視圖的控制器。

所以..例如在服務器上，你可能有這樣的MVC模式：

• 控制器接收HTTP請求並處理它。
• 它構建模型
• 該模型應用於視圖以生成HTML並將其作爲響應發回。

在客戶端將是類似（但有點在角的情況下不同）：

• 控制器被用來確定和操作模型。
• 該模型然後通過指令綁定到您的視圖。 （Angular實際上更像是MVVM模式，但它足夠相似）
• 該視圖通過指令類似地綁定到您的模型。 （這是MVVM部分的來源）。
• 這裏的想法是，模型和視圖都由指令保持最新。
• 控制器只包含操作模型的「業務邏輯」。

清澈如泥？

不用擔心。只知道這個：這只是一種常見的模式。這不是「特定服務器」或「客戶端特定」。任何需要將數據刷入模板輸出的任何地方都可以使用它。

---

編輯：更多的想法。

對於在服務器上提供JSON（甚至是XML）的Web API的情況，在大多數情況下您仍然使用MVC。這是因爲你正在做的是：

• 在控制器中處理請求。
• 在控制器中建立模型。
• 將模型渲染爲「視圖」，在這種情況下，該視圖是將視圖序列化爲JSON的視圖。

Answer 2

在昔日的好日子裏，客戶端只是一個展示。服務器負責與模型進行通信，應用業務邏輯，生成視圖並將靜態渲染內容發送回客戶端（瀏覽器）。

隨着網絡的成熟，其中一些職責從服務器遷移到客戶端。現在，服務器端通常是像RESTful API這樣的薄層，它存儲「官方」業務邏輯（而不是客戶端上的便捷邏輯）並存儲模型。但爲了提高性能和用戶體驗，客戶現在將模型的副本存儲在其自己的模型層中，並根據需要與服務器和/或本地存儲進行通信，並擁有自己的控制器和查看邏輯，以提供出色的用戶體驗。

那麼MVC仍然適用於服務器？是!它只是不同而已。服務器通常會生成客戶端應用程序運行的初始視圖（例如考慮本地化或國際化），並且仍然保留官方模型。但更重要的是，MVC中的「觀點」剛剛發生了變化。現在，客戶端應用程序消耗而不僅僅是呈現，而不是服務器端視圖爲HTML。

因此，爲了功能的緣故，我們仍然在服務器上使用MVC。但是爲了讓用戶體驗出色，我們現在也在客戶端使用MVC。