最近負責乙個專案，用了
但是隨著對業務邏輯理解的深入，才開始意識到問題的嚴重。
我錯誤地理解了 mvc 中的 controller，想當然地根據以往的經驗，把所有的業務邏輯都放在 controller 的 action 中去實現。
於是，每乙個 controller 的**都上千行，越來越臃腫。
最後，我下定決心重構**，起源是乙個對外開放 api 介面的需求。
按照現在的架構，**基本無法復用，我需要把很多功能再重複寫一遍，這實在是無法接受。
物件導向程式設計不僅僅是課本上的名詞啊！
真正開始實踐才發現，要有物件導向意識，有全域性觀，是多麼難得的一件事情。
1 到底什麼是 mvc
模型-檢視-控制器(mvc)是一種設計框架(設計模式)。
mvc 的目標是將業務邏輯從使用者介面的考慮中分離。
這樣，開發者就可以更容易地改變每一部分而不會影響其他。
在 mvc 中，model 代表資料和業務規則；
view 包含了使用者介面元素，例如文字，表單等；
controller 則管理模型和檢視中的通訊。
mvc 在各種程式語言中均有實現，例如 j2ee 應用開發中，
view 可能由 jsp 實現；controller 是乙個 servlet，現在一般用 struts 實現；model 則是由乙個實體 bean 來實現。
2 我遇到了什麼問題
yii framework 是乙個流行的 php 框架，它借鑑了 ruby on rails 的 activerecord(ar) 概念。
資料庫中的每乙個 table 都可以用 ar 類來方便地進行增刪改查操作。
它把 ar 當做 model，並推薦放在乙個名為 models 的目錄下面。
於是，我在自動生成表對應的 ar 之後，便望文生義想當然地認為已經擁有了 model 層。
其實，ar只不過是 dao (資料訪問層)，並不是 model 層。
我們的業務幾乎全放在了 controller 裡：對使用者提交上來的表單進行各種邏輯判斷，進行計算，例項化 ar 對資料進行儲存……
因為乙個 controller 中會有多個 action，每個 action 都有這樣的業務處理。
最後，我發現我的 controller **已經超過了 1000 行。
突然有一天，leader 說，我們這個系統要開放 api 給現有的舊系統呼叫，要給第三方介面。
第三方只是要給定乙個引數，本系統給出個結果值而已，這其中的業務處理它是不關心的。
壞就壞在這裡，controller 已經實現了那些業務，但它是接受表單提交的，怎樣能夠也接受 soap 的 xml 文件呢？
controller 和套套一樣，應該越薄越好。
它的職責應該只是接受使用者的輸入，然後立刻**給別的類來處理。
這樣 controller 只負責提供不同的介面，我們才能算是將業務邏輯分離出去，而分離出去的業務也很容易進行重用。
分離出來的這部分業務由誰來處理呢？答案應該是 model。
3 view的職責
view部分比較明確，就是負責顯示。
一切與顯示介面無關的東西，都不應該出現在view裡面。
因此，view中一般不應該出現複雜的判斷語句，以及複雜的運算過程。
可以有簡單的迴圈語句、格式化語句。比如，部落格首頁的文字列表就是一種迴圈。
對於php的web應用而言，html是view中的主要內容。
view應該從不呼叫model的寫方法。
也就是說，view只從model中讀取資料，但不改寫model。
所以我們說，view和model是老死不相往來的。
而且，view中不直接訪問$_get和$_post，應該由controller傳遞給view。
此外，view一般沒有任何準備資料處理的內容，如查詢資料庫等。
這些一般是放在controller裡面，並以變數的形式傳給檢視。
也就是說，檢視裡面要用到的資料，就是乙個變數。
4 model的職責
對於model而言，最主要就是儲存和輸出資訊。
比如，post類必然有乙個用於儲存部落格文章標題的title屬性，必然有乙個刪除的操作，這都是model的內容。
資料、行為、方法是model的主要內容。
實際工作中，model是mvc中**量最大。
model是邏輯最複雜的地方，因為應用的業務邏輯也要在這裡表示。
注意將model與controller區分開。
model是處理業務方面的邏輯，controller只是簡單的協調model和view之間的關係。
只要是與業務有關的，就該放在model裡面。
model不應該訪問request、session以及其他環境資料，這些應該由controller注入。
好的設計，應該是胖model，瘦controller。
5 controller的職責
對於controller，主要是響應使用者請求，決定使用什麼檢視，需要準備什麼資料用來顯示。
因此，對於request的訪問**，應該放在controller裡面，比如$_get、$_post等。
controller應該僅限於獲取使用者請求資料，不應該對資料有任何操作或預處理，這應該放在 model 裡面。
對於資料的寫操作，要呼叫model類的方法完成。
對於使用者請求的響應，要呼叫檢視渲染。
此外，一般不要有html**等其他表現層的東西，這應該是屬於view的內容。
6 啟示
簡言之，rich model is better。
mvc 職能劃分 MVC的劃分原則
mvc的劃分原則 對於mvc中三者的劃分並沒有十分明晰的定義和界線，只是一種指導思想，讓你按照model，view，controller三個方面來描述你的應用，並通過這三者的的互動，使應用功能得以正常運轉。其中，view的部分比較明確，就是負責顯示。一切與顯示介面無關的東西，都不應該出現在view裡...
MVC架構的職責劃分
模型 檢視 控制器 mvc 是一種設計框架 設計模式 mvc 的目標是將業務邏輯從使用者介面的考慮中分離。這樣，開發者就可以更容易地改變每一部分而不會影響其他。在 mvc 中，view 可能由 jsp 實現 controller 是乙個 servlet，現在一般用 struts 實現 model 則...
MVC架構的職責劃分原則
mvc設計原則 模型 檢視 控制器 mvc 是一種設計框架 設計模式 mvc 的目標是將業務邏輯從使用者介面的考慮中分離。這樣，開發者就可以更容易地改變每一部分而不會影響其他。在 mvc 中 model 代表資料和業務規則 view 包含了使用者介面元素，例如文字，表單等 controller 則管...