MVC設計模式
是一種使用 MVC(Model View Controller 模型-視圖-控制器)設計創(chuàng)建 Web 應用程序的模式:Model(模型)表示應用程序核心(比如數據庫記錄列表)、View(視圖)顯示數據(數據庫記錄)、Controller(控制器)處理輸入(寫入數據庫記錄)是一種設計模式根據項目具體需求確定是否使用嫩舟。
![MVC設計模式](http://ogpt2m9nl.bkt.clouddn.com/MVC 上午9.44.27 上午9.45.30.png)
用戶在View上觸發(fā)通過Controller處理業(yè)務用于更新數據,數據更新后發(fā)送消息用于改變顯示或Controller直接反饋用戶怀偷。在MVC基礎上為了更好的復用(高內聚低耦合)降低View與Model的耦合家厌,從而進行改進:
![優(yōu)化后](http://ogpt2m9nl.bkt.clouddn.com/%E6%9C%AA%E5%91%BD%E5%90%8D.png)
看起來是不是很像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模式合理的搭配使用涧郊。