MVC設計模式
是一種使用 MVC（Model View Controller 模型-視圖-控制器）設計創(chuàng)建 Web 應用程序的模式：Model（模型）表示應用程序核心（比如數據庫記錄列表）、View（視圖）顯示數據（數據庫記錄）、Controller（控制器）處理輸入（寫入數據庫記錄）是一種設計模式根據項目具體需求確定是否使用嫩舟。
用戶在View上觸發(fā)通過Controller處理業(yè)務用于更新數據，數據更新后發(fā)送消息用于改變顯示或Controller直接反饋用戶怀偷。在MVC基礎上為了更好的復用（高內聚低耦合）降低View與Model的耦合家厌，從而進行改進：
看起來是不是很像MVP?
同樣的切斷了View與Model的聯(lián)系，Controller/Presenter負責邏輯的處理枢纠，Model提供數據像街，View負責顯示。在MVP里晋渺，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現(xiàn)脓斩。而且木西，Presenter與具 體的View是沒有直接關聯(lián)的，而是通過定義好的接口進行交互随静，從而使得在變更View時候可以保持Presenter的不變八千，即重用。這段描述摘自
MVP的優(yōu)點：
- 模型與視圖完全分離燎猛，我們可以修改視圖而不影響模型恋捆；
- 可以更高效地使用模型，因為所有的交互都發(fā)生在一個地方——Presenter內部重绷；
- 我們可以將一個Presenter用于多個視圖沸停，而不需要改變Presenter的邏輯。這個特性非常的有用昭卓，因為視圖的變化總是比模型的變化頻繁愤钾；
- 如果我們把邏輯放在Presenter中瘟滨，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）。
改進后降低了View與Controller的耦合能颁，所有的消息處理交給Controller杂瘸。這是種非常理想的狀態(tài)，明顯優(yōu)于原始的MVC伙菊。但在實際開發(fā)中所有View與Model交互通過Controller后會造成Controller上邏輯過于復雜代碼臃腫败玉。
在此基礎上我們繼續(xù)優(yōu)化參考objc.io：
- 將TableView的DataSource分離出來
- 將網絡請求和Model轉換分離到另外一個類中
- 將拼裝復用的控件拆分到另一個類中
如何得到的上述結論？
很多設計模式都遵循共同的特點“可維護”镜硕，對于View及Model來說绒怨，如果抽象的好、封裝的好谦疾，就可以隨意哪類復用南蹂，也便于維護。Model是業(yè)務數據如果可以在同一個項目內也可以復用念恍。而Controller中包含網絡請求六剥、數據處理、以及交互邏輯無法復用且臃腫峰伙。所以在MVC的基礎上我們可以針對“腫塊”“切開”重組疗疟。
- 針對網絡請求數據處理：
唐巧曾介紹過將每個網絡請求抽象成單獨的類[把每一個網絡請求封裝成對象其實是使用了設計模式中的 Command 模式：將請求封裝成對象，以便使用不同的請求瞳氓、日志策彤、隊列等來參數化其他對象。命令模式也支持撤銷操作]
優(yōu)點：
* 方便更換第三方依賴庫
* 在積累中處理公共邏輯匣摘、緩存邏輯
* 方便對象持久化
* 簡化Controller邏輯
- 將拼裝控件抽象到專門的類中
可復用的控件封裝店诗、
用一個靜態(tài)類幫助拼裝、
我們在拆分Controller的過程中對于Controller與View的傳值過程拿出來抽象音榜，便成了ViewModel庞瘸，數據庫結構往往是不能直接跟界面控件一一對應上的，所以赠叼，需要再定義一個數據對象專門對應view上的控件擦囊。而ViewModel的職責就是把model對象封裝成可以顯示和接受輸入的界面數據對象。
看到這里是不是已經像MVVM模式了嘴办？我的理解是實際上Model-ViewModel-ViewController-View其實就是MVC基礎上將臃腫的Controller拆分開來瞬场。 在實際應用中無需拘泥于形式一定是MVC模式或者MVVM模式、MVP模式合理的搭配使用涧郊。
