前言：設(shè)計模式的使用是為了使代碼邏輯清晰躏救，以一種大家普遍認(rèn)可的思路組織代碼結(jié)構(gòu)，特定的模式可以解決特定的問題螟蒸，同時也便于其他人閱讀和維護盒使。MVC是一種代碼結(jié)構(gòu)組織方式，涉及到多種設(shè)計模式七嫌，包括組合模式少办、策略模式、觀察者模式诵原。
說起MVC英妓，似乎每個人都知道，MVC即Model绍赛、View蔓纠、Controller(模型、視圖吗蚌、控制器)贺纲，大部分人應(yīng)該也知道這個關(guān)系圖：
但實際開發(fā)中是否真正利用到了MVC模式的精華之處，或者說是否真的知道MVC的精華之處褪测。
我看過的大部分代碼，包括我自己以前寫的潦刃，結(jié)構(gòu)基本就是View層是界面侮措，Controller層是業(yè)務(wù)邏輯，Model層是數(shù)據(jù)結(jié)構(gòu)這樣的代碼結(jié)構(gòu)乖杠，而幾乎所有的邏輯分扎、數(shù)據(jù)操作、處理胧洒，UI模塊的調(diào)用畏吓、事件響應(yīng)都集中在Controller層（可以臃腫到好幾百行）墨状。
這樣的結(jié)構(gòu)唯一的優(yōu)點就是什么都不用考慮，上來就是直接開干菲饼，不得不說Apple基本類的封裝也是為程序員考慮肾砂，UIViewController、UIView宏悦、NSObject三者的結(jié)合使這樣的代碼結(jié)構(gòu)也看起來似乎合情合理(說實話這種樸素的代碼使用和閱讀都挺方便的镐确，所有代碼都是直來直去)。
如果沒有清晰的結(jié)構(gòu)和各自獨立的模塊封裝饼煞，在代碼量大源葫、結(jié)構(gòu)和功能相對復(fù)雜、有功能需要調(diào)整的時候這種代碼的維護就變得很麻煩了砖瞧。你有沒有過開發(fā)類似功能時要復(fù)制大量代碼的經(jīng)歷息堂？有沒有自測時感覺無從下手？有沒有在多個人開發(fā)一個功能時頻頻發(fā)生沖突块促？
MVC正是解決代碼結(jié)構(gòu)關(guān)系一種流行的方式荣堰，它和曾經(jīng)也流行過的三層架構(gòu)(UI層表示用戶界面，BLL層表示業(yè)務(wù)邏輯褂乍，DAL層表示數(shù)據(jù)訪問)極其相似持隧，而大部分人也正是把MVC當(dāng)做三層架構(gòu)在使用和理解，如果是這樣逃片，那么你可能就錯過了MVC的精華部分屡拨。
MVC設(shè)計的初衷是要將軟件用戶界面和業(yè)務(wù)邏輯分離以使代碼可擴展性、可復(fù)用性褥实、可維護性呀狼、靈活性加強。View層是界面损离，Model層是業(yè)務(wù)邏輯哥艇，Controller層用來調(diào)度View層和Model層，將用戶界面和業(yè)務(wù)邏輯合理的組織在一起僻澎。
所以Controller中的內(nèi)容應(yīng)該盡量簡潔貌踏，以提供View和Model最大的靈活性。各Model之間是可以相互調(diào)用的窟勃， Controller也可以無障礙的調(diào)用Model祖乳，因此將業(yè)務(wù)邏輯放在Model中可以靈活的使用組合的方式復(fù)用代碼。
各層關(guān)系詳解：
View—>Model —— view需要model的數(shù)據(jù)做顯示
Model—>View —— model的數(shù)據(jù)改變時需要通知view
View—>Controller —— view發(fā)生某些事件時通知Controller秉氧，而Controller根據(jù)情況通知model
Controller—>View —— Controller作為載體加載view
Controller—>Mode —— Controller調(diào)用model的業(yè)務(wù)邏輯
比方說眷昆，有一個View會提交數(shù)據(jù)給Model進行處理以實現(xiàn)具體的行為，View通常不會直接提交數(shù)據(jù)給Model，它會先把數(shù)據(jù)提交給Controller亚斋，然后Controller再將數(shù)據(jù)轉(zhuǎn)發(fā)給Model作媚。
假如此時程序業(yè)務(wù)邏輯的處理方式有變化，那么只需要在Controller中將原來的Model換成新實現(xiàn)的Model就可以了(這當(dāng)然還需要View合理的接口封裝)帅刊，控制器的作用就是這么簡單纸泡， 用來將不同的View和不同的Model組織在一起，順便替雙方傳遞消息厚掷，僅此而已弟灼。
總結(jié)MVC的好處就是：耦合性低，視圖層和業(yè)務(wù)層分離冒黑，重用性高田绑，應(yīng)用更易于維護、修改和單元測試抡爹。
但也不是沒有缺點的：①在小型規(guī)模的項目中使用會顯得殺雞用牛刀而得不償失掩驱；②視圖與控制器間連接緊密，需要定義消息傳遞接口冬竟；③視圖對模型數(shù)據(jù)的訪問效率低欧穴，視圖不直接調(diào)用模型而是使用接口，所以模型內(nèi)部可能會有多余的操作或者數(shù)據(jù)未變化而頻繁的訪問泵殴。
