MVC的弊端git
厚重的View Controllergithub
M:模型model的對象一般很是的簡單。根據Apple的文檔,model應包括數據和操做數據的業務邏輯。而在實踐中,model層每每很是薄,無論怎樣,model層的業務邏輯不該被拖入到controller。面試
V:視圖view一般是UIKit控件(component,這裏根據習慣譯爲控件)或者編碼定義的UIKit控件的集合。View的如何構建(PS:IB或者手寫界面)何須讓Controller知曉,同時View不該該直接引用model(PS:現實中,你懂的!),而且僅僅經過IBAction事件引用controller。業務邏輯很明顯不納入view,視圖自己沒有任何業務。算法
C:控制器controller。Controller是app的「膠水代碼」:協調模型和視圖之間的全部交互。控制器負責管理他們所擁有的視圖的視圖層次結構,還要響應視圖的loading、appearing、disappearing等等,同時每每也會充滿咱們不肯暴露的model的模型邏輯以及不肯暴露給視圖的業務邏輯。網絡數據的請求及後續處理,本地數據庫操做,以及一些帶有工具性質輔助方法都加大了Massive View Controller的產生。數據庫
遺失(無處安放)的網絡邏輯
蘋果使用的MVC的定義是這麼說的:全部的對象均可以被歸類爲一個model,一個view,或是一個controller。swift
你可能試着把它放在Model對象裏,可是也會很棘手,由於網絡調用應該使用異步,這樣若是一個網絡請求比持有它的model生命週期更長,事情將變的複雜。顯然View裏面作網絡請求那就更格格不入了,所以只剩下Controller了。若這樣,這又加重了Massive View Controller的問題。若不這樣,何處纔是網絡邏輯的家呢?設計模式
因爲View Controller混合了視圖處理邏輯和業務邏輯,分離這些成分的單元測試成了一個艱鉅的任務。數組
一種能夠很好地解決Massive View Controller
問題的辦法就是將 Controller 中的展現邏輯抽取出來,放置到一個專門的地方,而這個地方就是 viewModel
。MVVM衍生於MVC,是對 MVC 的一種演進,它促進了 UI 代碼與業務邏輯的分離。它正式規範了視圖和控制器緊耦合的性質,並引入新的組件。他們之間的結構關係以下:微信
MVVM
中,view
和 view controller
正式聯繫在一塊兒,咱們把它們視爲一個組件view
和 view controller
都不能直接引用model
,而是引用視圖模型(viewModel
)viewModel
是一個放置用戶輸入驗證邏輯,視圖顯示邏輯,發起網絡請求和其餘代碼的地方MVVM
會輕微的增長代碼量,但整體上減小了代碼的複雜性view
引用viewModel
,但反過來不行(即不要在viewModel
中引入#import UIKit.h
,任何視圖自己的引用都不該該放在viewModel
中)(PS:基本要求,必須知足)viewModel
引用model
,但反過來不行* MVVM 的使用建議MVVM
能夠兼容你當下使用的MVC
架構。MVVM
增長你的應用的可測試性。MVVM
配合一個綁定機制效果最好(PS:ReactiveCocoa你值得擁有)。viewController
儘可能不涉及業務邏輯,讓 viewModel
去作這些事情。viewController
只是一箇中間人,接收 view
的事件、調用 viewModel
的方法、響應 viewModel
的變化。viewModel
絕對不能包含視圖 view(UIKit.h)
,否則就跟 view
產生了耦合,不方便複用和測試。viewModel
之間能夠有依賴。viewModel
避免過於臃腫,不然重蹈Controller
的覆轍,變得難以維護。View
能夠獨立於Model
變化和修改,一個 viewModel
能夠綁定到不一樣的 View
上viewModel
裏面,讓不少 view
重用這段視圖邏輯viewModel
,設計人員能夠專一於頁面設計MVVM
模式能夠針對 viewModel
來進行測試Bug
很難被調試。你看到界面異常了,有多是你 View
的代碼有 Bug
,也多是 Model
的代碼有問題。數據綁定使得一個位置的 Bug
被快速傳遞到別的位置,要定位原始出問題的地方就變得不那麼容易了。Item
對象,若是Item對象中還有相似數組,就很頭疼。Item
)的可複用程度才高,不然容易出現類型爆炸,提升維護成本。NSDictionary/NSArray
直觀。MVC
的設計模式也並不是是病入膏肓,無藥可救的架構,最起碼目前MVC設計模式仍舊是iOS開發的主流框架,存在即合理。針對文章所述的弊端,咱們依舊有許多可行的方法去避免和解決,從而打造一個輕量級的ViewController
。網絡
MVVM
是MVC
的升級版,徹底兼容當前的MVC架構,MVVM雖然促進了UI 代碼與業務邏輯的分離,必定程度上減輕了ViewController
的臃腫度,可是View
和ViewModel
之間的數據綁定使得 MVVM變得複雜和難用了,若是咱們不能更好的駕馭二者之間的數據綁定,一樣會形成Controller 代碼過於複雜,代碼邏輯不易維護的問題。
一個輕量級的ViewController
是基於MVC
和MVVM
模式進行代碼職責的分離而打造的。MVC和MVVM有優勢也有缺點,但缺點在他們所帶來的好處面前時不值一提的。他們的低耦合性,封裝性,可測試性,可維護性和多人協做便利大大提升了開法效率。
同時,咱們須要保持的是一個擁抱變化的心,以及理性分析的態度。在新技術的面前,不盲從,也不守舊,一切的決策都應該創建在認真分析的基礎上,這樣才能應對技術的變化。
做者:iOS猿_員
連接:https://www.jianshu.com/p/d0bc12a63ccf