mvc應(yīng)該是在web端來(lái)說(shuō)很常用且簡(jiǎn)單的一種設(shè)計(jì)思想了 ，mvc分別代表了
m model 模型（操作數(shù)據(jù)）
v view 視圖（頁(yè)面交互）
c controller 控制器（處理業(yè)務(wù)邏輯）
??????? 這種思想我個(gè)人認(rèn)為沒(méi)有完全實(shí)現(xiàn)面向?qū)ο蟮乃枷耄簿褪窃诤芏嗲闆r下沒(méi)有做到代碼最優(yōu)化，好多時(shí)候（比如修改需求的階段）可能無(wú)法做到代碼的重用，同樣一段代碼可能需要粘貼好幾個(gè)地方調(diào)用。當(dāng)然好處也顯而易見(jiàn)，簡(jiǎn)單易懂，上手快，開(kāi)發(fā)階段速度快。
??????? 那mvc是如何工作的呢？？控制器層通過(guò)業(yè)務(wù)邏輯，進(jìn)行數(shù)據(jù)交互。過(guò)程很簡(jiǎn)單，基本原則是每個(gè)表都單獨(dú)建一個(gè)類，流程可以這樣理解（舉一個(gè)用戶留言的例子），基本操作有以下幾步
（1）驗(yàn)證用戶是否登錄（只有登錄用戶才能留言）
（2）驗(yàn)證文章是否存在、狀態(tài)是否允許留言
（3）檢查用戶當(dāng)天對(duì)該文章是否有留言（一個(gè)用戶規(guī)定當(dāng)天對(duì)同一個(gè)文章只能留言一次）
（4）檢查用戶當(dāng)天所有留言總數(shù)是否大于20（一個(gè)用戶最多每天只能留言20次）
（5）插入留言庫(kù)
（6）更新緩存
（7）插入記錄表
（8）給用戶發(fā)短信或郵件
（9）統(tǒng)計(jì)留言信息來(lái)源（如app留言用戶需要統(tǒng)計(jì)手機(jī)型號(hào)和下載市場(chǎng)等信息）
這幾個(gè)步驟之間有的有依賴關(guān)系，有的沒(méi)有。如果用mvc的思路來(lái)做的話，會(huì)有一個(gè)盛放了很多業(yè)務(wù)邏輯的控制器，不斷的調(diào)用處理數(shù)據(jù)的model類。這樣寫的優(yōu)勢(shì)和劣勢(shì)都很明顯
優(yōu)勢(shì)：典型的面向過(guò)程的寫法，前期代碼開(kāi)發(fā)快速
劣勢(shì)：代碼依賴性強(qiáng)，后期遇到大的功能修改的時(shí)候會(huì)非常痛苦。
??????? 隨著時(shí)間的推移，現(xiàn)有的業(yè)務(wù)邏輯要改變，現(xiàn)在不要求對(duì)用戶每天針對(duì)同一篇文章的留言次數(shù)做限制，可以無(wú)限留言。因?yàn)樾枨蟊容^簡(jiǎn)單，那現(xiàn)在只需要把做限制的代碼給刪除即可。但如果現(xiàn)在有個(gè)比較大的業(yè)務(wù)需求，有一些文章是比特殊的（比如很敏感），我們?cè)诹粞缘臅r(shí)候?qū)λ牧粞詳?shù)量是沒(méi)有限制并且是不用給用戶發(fā)短信或郵件的。這時(shí)候會(huì)有兩種思路，一種是在原來(lái)的控制器中，加各種判斷（強(qiáng)烈不建議，以為隨著以后業(yè)務(wù)邏輯的復(fù)雜和變化，條件判斷越來(lái)越多，代碼會(huì)越來(lái)越難以維護(hù)）。第二種，是重新建立一個(gè)控制器，針對(duì)特殊文章讓他們走一個(gè)專門的控制器，這時(shí)候的劣勢(shì)就顯現(xiàn)出來(lái)了，你需要復(fù)制大部分代碼過(guò)來(lái)，明明是80%的代碼是一模一樣的，看來(lái)像是可以復(fù)用的，但怎么就用不了呢？這就是mvc的劣勢(shì)，沒(méi)辦法很好的做到代碼的復(fù)用，也就是沒(méi)能完全實(shí)現(xiàn)面向?qū)ο螅ㄖ辽僭谶@里沒(méi)有實(shí)現(xiàn)吧！）
????? 那如果現(xiàn)在，有這樣一個(gè)在控制器和model之間的中間層，專門用來(lái)做一些階段性的工作，比如做包含了1 2 3 4 個(gè)操作的內(nèi)容，這時(shí)候我們遇到大的需求改動(dòng)的時(shí)候就不需要每次都把所有的業(yè)務(wù)邏輯修改一邊了，只需要建立專門盛放階段性任務(wù)的factory，然后通過(guò)控制器調(diào)用。這就是MCF.或者也可以把factory叫做Library.
