這是真的MVC設計模式還是我應該稱之爲別的？

Question

這是一個關於理論的問題，所以不需要代碼片段。

我構建了一個路由器，作爲典型的路由器，它根據URL調度控制器。工作流程是這樣的：

1. 路由器調度控制器和對其進行實例
2. 控制器呈現視圖
3. 用戶的觀點
基於用戶交互
4. 控制器更新模型
5. 模型返回的相互作用數據新狀態到控制器
6. 控制器根據新數據更新視圖

所以基本上，控制器是模型和視圖之間的起點和鏈接。模型和視圖不會直接相互影響。控制器是主力，擁有大部分代碼。

現在，這一切都很好，我明白了。當我閱讀有關MVC設計模式的文章並意識到他們描述的內容不是我剛纔所描述的時候，就會產生混淆。看起來好像是從視圖開始的模式。該視圖直接與模型對話，並且控制器接受用戶交互以更新模型。因此，我正在做的事情可能涉及模型，視圖和控制器，但它並不嚴格的MVC設計模式。我確實讀過一篇文章，他們稱我最初描述爲CAV，控制器操作視圖。

我的問題是，我在描述什麼？如果它實際上不是MVC，我不想繼續將其作爲MVC。從我看過的書中看，70年代MVC誕生了。從那以後事情發生了變化。也許我正在做的是一些MVC的演變版本，但不是嚴格的MVC。是否有另一個名稱，以便我可以通過將其稱爲MVC來阻止對自己和其他人的混淆？

Answer 1

我認爲它的語言（技術）依賴。 你用php標籤標記了你的問題，所以我想你正在開發使用這種語言的應用程序。在經典的PHP應用程序中，視圖無法從模型中獲取更新（實際上，這與僅在服務器上執行的PHP語言更相關）。

首先，對於每個請求啓動整個應用程序，並在所有響應已發送時終止。所以，每個請求都會調用路由器。

然後，路由器執行必須處理請求的控制器（根據路由規則）。

請求正在讀取或寫入不會修改此行爲。

如果你想允許以索要數據修改審批到控制器，你可能需要使用一些客戶端編程語言（JavaScript）的。因此，您可以使用一個REST API來處理模型和視圖之間的通信。

要回答你的問題，我覺得你不能沒有使用客戶端上的編程語言實現純 MVC設計上的客戶端 - 服務器模型模式。

Answer 2

即使我以前遇到過這種困惑。在原始形式中，View確實與控制器進行了交互。他們遵循觀察者可觀察的模式。這就是MVC在SmallTalk中的構想。但是，您所談論的MVC版本實際上是它的一個現代版本，並且在大多數框架中使用。它已成爲一種標準。我不知道有任何其他用語。在這個版本中，控制器實際上是視圖和模型之間的橋樑。然而，這兩種模式實現了關注點分離的期望目標。