最近打算學習PHP框架，才發現我以前對MVC的認識很膚淺。但是看Laravel的文檔，對MVC又是雲裡霧裡的
比如說寫一個 Todo List, 依照前端的 MVC 這樣寫:
一般有這樣的關係(不是很準確, 而且各種 MVC 實現也不完全一致):
整體上是一個循環~ 從 Model 開始, 中間加上用戶操作, 又作用回到 Model 這是寫圖形的一個思路, 就是把資料跟介面區分開來, 簡化程式. 或說, 抽像出表示一個介面最少的資料作為 Model, 最少的操作作為 Controller. 而 View, 跟著 Model 變, 甚至根據用戶需要隨意進行更改.
大致上:
或:
以下答案屬個人見解，若有錯求大神指正。
先說下原生PHP吧。 資料處理，頁面顯示在一起，互相嵌套。
MVC就不一樣，資料處理和展示是分開的。 業務不複雜的時候基本V和C就能搞定。 C哥把資料處理好，打包交給V。鄭重的給V說：「V哥，數據都在這裡了，您拿去展示吧！」 V說：「好的C哥！」 然後就把數據展現在前端。 V哥也有類似foreach等的語法，用來展示C哥給的資料。
有時候業務複雜了，C哥一個人處理數據有點累，C哥就喊M哥來幫忙。 M哥幫C哥做一些重複性工作，處理好後給C哥。再由C哥轉交給V哥。
原生PHP就像是外包，往往一個人就得處理前端後端的東西。 MVC就像一個成熟的公司，有前端有後端。分工明確。
概念大家都說了，其實MVC的涵義一直在潛移默化地變化，原本CS軟體的MVC和如今php ruby python講的MVC已經有不小的區別了。甚至很可能概念早就變成MVP，只是大家習慣了MVC，指鹿為馬了
我覺得已實際專案來說，作3個思想實驗就能大致理解MVC的本質和目標，具體三層怎麼分，是三層還是四層還是兩層，其實都是為了達成靈活性和可維護性的手段而已
資料結構不變，把資料庫從mysql遷移到pgsql乃至mongodb，你的專案需要多大的變化？ 理想的MVC架構應該無需修改任何業務代碼(包括Model)，只需要修改配置文件，最多寫個新的DBAL driver 實際情況下不同DB的能力有微妙的差別，那也應該微調Model就能解決。
如果你的答案是兩眼一黑：和重寫一遍差不多，那麼你的M層還不夠獨立，該寫在Model的程式碼分散到別處了
假設保持所有功能不變（都有合理自然的行動版互動），為你的網站增加手機版，你的專案需要多大的變化？ 答案應該是重寫一套View，然後Controller改一行if(isMobile) use(MobileView);
if(isMobile) use(MobileView);
如果你發現Controller要改大量邏輯，甚至Model都被牽連，那你的V層不夠獨立
假設所有功能不變，為你的網站增加開放API（給第三方或行動應用程式使用），你的專案需要多大的改變？ 答案應該是一套新的Controller 包含新的授權、和資料格式以及校驗等邏輯，和一個簡單的View（只輸出json或xml）
如果你發現Model要改，原來View裡的東西要挪動，或者是原來寫在老的Controller裡的部分程式碼要copy一遍，那麼你的C層不夠獨立
最簡單的莫過於把MVC比喻成小時候玩的插卡式的遊戲機： M：就是遊戲卡，保存數據，負責業務邏輯等 V：就是電視機，負責呈現遊戲的畫面 C：就是遊戲控製手柄，負責前兩者之間的互動
拿一個購物網站舉例。 M提供了資料模型，例如網站的使用者資料包括使用者名，密碼，郵箱，每個使用者可以下多個訂單，每個訂單有訂單編號，價格等等。 V提供了一個視圖，就是你看到的HTML介面是什麼樣的，例如商品清單的呈現，個人歷史訂單的呈現。 C是控制器，負責從M中提取數據，然後在V中如何呈現。例如你要查看最近一周個人訂單歷史的時候，V負責從M中找到你所有的訂單，過濾掉一周以前的訂單數據，然後把剩下的提供給V來展示。
理解mvc的前提是有程式碼分層的概念，而程式碼分層的目的是解耦。
請試著解答兩個問題：
一個軟體從用戶觸發視圖上的業務需求，到程式按照一定的業務邏輯處理這個需求，再到將處理結果在視圖的上反饋給用戶，整個過程中的程式碼負責的主要任務有三個切面，即：視圖的操作，業務邏輯的處理，視圖和業務邏輯之間的對接。
在程式中如果程式碼不分層的話，那麼這個三個切面的實作會耦合在一個類別中。為了程式碼的可維護性、可讀性、靈活性（請參考@mcfog的答案），就應該將這些程式碼按照切面分別寫到不同的類別中，進而將相同切面的類別放到一個套件中，這些類別和包看起來像在不同的層面上。
mvc是成熟的分層（解耦）方案。
根據第一個問題的回答，要將不同層面的程式碼放到不同的類別（和套件）中，那麼這些不同層次的程式碼如何協作？
此問題的其他答案看起來已經具體地，並且圖文並茂地回答了這個問題。
Model中的程式碼負責業務邏輯； View中的程式碼負責使用者互動； Controller中的程式碼負責model和view的對接。
Model View Controller 模型，視圖，控制器 模型:資料模型 檢視:UI相關元素 控制器:用來把模型和視圖連結起來
越簡單越好是吧？
M：模型－你如何為資料建模，或者說你的資料用何種結構表示
C：控制器－你如何處理業務邏輯，這個「處理」主要是對應兩個端：一端是向模型請求處理需要的資料來源；另一端則是把處理結果用某種方式傳遞給視圖；中間的具體流程就是控制器負責的層面
V：視圖－你如何向客戶端呈現業務處理的結果以及提供互動
其實說的太簡單了也不好，因為有些細節為了簡化只能高度概括和抽象，若是沒有足夠的知識和經驗支撐就如同霧裡看花。
看了樓上各位的回答，最後覺的：V是給用戶看的 C是給用戶控制的 M是用戶接觸不到的 透過C和V對M進行控制？
SO上關於MVC的討論：What is MVC, really?
簡單點說，就是別把 查資料庫(Model) 和 展示資料的(View) 程式碼 攪和在一起，如果還有些業務邏輯要加進來，那就是 控制器(Controller)
比如說寫一個 Todo List, 依照前端的 MVC 這樣寫:
一般有這樣的關係(不是很準確, 而且各種 MVC 實現也不完全一致):
整體上是一個循環~ 從 Model 開始, 中間加上用戶操作, 又作用回到 Model
這是寫圖形的一個思路, 就是把資料跟介面區分開來, 簡化程式.
或說, 抽像出表示一個介面最少的資料作為 Model, 最少的操作作為 Controller.
而 View, 跟著 Model 變, 甚至根據用戶需要隨意進行更改.
大致上:
或:
以下答案屬個人見解，若有錯求大神指正。
先說下原生PHP吧。
資料處理，頁面顯示在一起，互相嵌套。
MVC就不一樣，資料處理和展示是分開的。
業務不複雜的時候基本V和C就能搞定。
C哥把資料處理好，打包交給V。鄭重的給V說：「V哥，數據都在這裡了，您拿去展示吧！」
V說：「好的C哥！」 然後就把數據展現在前端。 V哥也有類似foreach等的語法，用來展示C哥給的資料。
有時候業務複雜了，C哥一個人處理數據有點累，C哥就喊M哥來幫忙。
M哥幫C哥做一些重複性工作，處理好後給C哥。再由C哥轉交給V哥。
原生PHP就像是外包，往往一個人就得處理前端後端的東西。
MVC就像一個成熟的公司，有前端有後端。分工明確。
概念大家都說了，其實MVC的涵義一直在潛移默化地變化，原本CS軟體的MVC和如今php ruby python講的MVC已經有不小的區別了。甚至很可能概念早就變成MVP，只是大家習慣了MVC，指鹿為馬了
我覺得已實際專案來說，作3個思想實驗就能大致理解MVC的本質和目標，具體三層怎麼分，是三層還是四層還是兩層，其實都是為了達成靈活性和可維護性的手段而已
更換資料庫選擇
資料結構不變，把資料庫從mysql遷移到pgsql乃至mongodb，你的專案需要多大的變化？
理想的MVC架構應該無需修改任何業務代碼(包括Model)，只需要修改配置文件，最多寫個新的DBAL driver
實際情況下不同DB的能力有微妙的差別，那也應該微調Model就能解決。
如果你的答案是兩眼一黑：和重寫一遍差不多，那麼你的M層還不夠獨立，該寫在Model的程式碼分散到別處了
手機HTML5版本
假設保持所有功能不變（都有合理自然的行動版互動），為你的網站增加手機版，你的專案需要多大的變化？
答案應該是重寫一套View，然後Controller改一行
if(isMobile) use(MobileView);如果你發現Controller要改大量邏輯，甚至Model都被牽連，那你的V層不夠獨立
增加API
假設所有功能不變，為你的網站增加開放API（給第三方或行動應用程式使用），你的專案需要多大的改變？
答案應該是一套新的Controller 包含新的授權、和資料格式以及校驗等邏輯，和一個簡單的View（只輸出json或xml）
如果你發現Model要改，原來View裡的東西要挪動，或者是原來寫在老的Controller裡的部分程式碼要copy一遍，那麼你的C層不夠獨立
最簡單的莫過於把MVC比喻成小時候玩的插卡式的遊戲機：
M：就是遊戲卡，保存數據，負責業務邏輯等
V：就是電視機，負責呈現遊戲的畫面
C：就是遊戲控製手柄，負責前兩者之間的互動
拿一個購物網站舉例。
M提供了資料模型，例如網站的使用者資料包括使用者名，密碼，郵箱，每個使用者可以下多個訂單，每個訂單有訂單編號，價格等等。
V提供了一個視圖，就是你看到的HTML介面是什麼樣的，例如商品清單的呈現，個人歷史訂單的呈現。
C是控制器，負責從M中提取數據，然後在V中如何呈現。例如你要查看最近一周個人訂單歷史的時候，V負責從M中找到你所有的訂單，過濾掉一周以前的訂單數據，然後把剩下的提供給V來展示。
理解mvc的前提是有程式碼分層的概念，而程式碼分層的目的是解耦。
請試著解答兩個問題：
程式碼為什麼要解耦
一個軟體從用戶觸發視圖上的業務需求，到程式按照一定的業務邏輯處理這個需求，再到將處理結果在視圖的上反饋給用戶，整個過程中的程式碼負責的主要任務有三個切面，即：視圖的操作，業務邏輯的處理，視圖和業務邏輯之間的對接。
在程式中如果程式碼不分層的話，那麼這個三個切面的實作會耦合在一個類別中。為了程式碼的可維護性、可讀性、靈活性（請參考@mcfog的答案），就應該將這些程式碼按照切面分別寫到不同的類別中，進而將相同切面的類別放到一個套件中，這些類別和包看起來像在不同的層面上。
如何解耦
mvc是成熟的分層（解耦）方案。
根據第一個問題的回答，要將不同層面的程式碼放到不同的類別（和套件）中，那麼這些不同層次的程式碼如何協作？
此問題的其他答案看起來已經具體地，並且圖文並茂地回答了這個問題。
Model中的程式碼負責業務邏輯；
View中的程式碼負責使用者互動；
Controller中的程式碼負責model和view的對接。
Model View Controller 模型，視圖，控制器
模型:資料模型
檢視:UI相關元素
控制器:用來把模型和視圖連結起來
越簡單越好是吧？
M：模型－你如何為資料建模，或者說你的資料用何種結構表示
C：控制器－你如何處理業務邏輯，這個「處理」主要是對應兩個端：一端是向模型請求處理需要的資料來源；另一端則是把處理結果用某種方式傳遞給視圖；中間的具體流程就是控制器負責的層面
V：視圖－你如何向客戶端呈現業務處理的結果以及提供互動
其實說的太簡單了也不好，因為有些細節為了簡化只能高度概括和抽象，若是沒有足夠的知識和經驗支撐就如同霧裡看花。
看了樓上各位的回答，最後覺的：V是給用戶看的 C是給用戶控制的 M是用戶接觸不到的 透過C和V對M進行控制？
SO上關於MVC的討論：What is MVC, really?
簡單點說，就是別把 查資料庫(Model) 和 展示資料的(View) 程式碼 攪和在一起，如果還有些業務邏輯要加進來，那就是 控制器(Controller)