前言
以前對mvvm的理解僅僅是將控制器的一些業務邏輯以及一些網絡請求等與UI無關的東西盡量放到vm中去做,自從看完了梁士興與臧成威大大的演講對其有了更進一步的認識.以下圖片均來自梁士興與臧成威大大的演講PPT.
業務發展所面臨的挑戰,順便感謝下大神得分享.
屏幕快照
屏幕快照
隨著美團的發展,他的業務也變得復雜起來,主要面臨的挑戰就是代碼的可復用性降低,放大了業務的差異性,以及在復雜的業務需求下,對不同能力的工程師進行分配任務缺少指導原則.美團的做法是從拆做起,改善架構設計,提升代碼復用.
解決方法
屏幕快照
對架構進行了重新設計,引入了MVVM架構與響應式編程,通過將業務邏輯拆分到vm中,這樣初中級的工程師可以去寫UI,而富有經驗的工程師負責去寫VM(業務邏輯),同時將業務邏輯抽取出來也可以提高代碼的復用性.但我個人認為這里有一個弊端,就是長期從事單一的方向編寫對工程師的個人成長并沒有什么好處.
綁定
我們可以將cell的顯示的數據放入到VM中,通過RAC的綁定,將cell的元素與VM暴露出來的屬性綁定在一起,這樣當數據變化的時候,我們并不需要刷新cell就可以做到動態的變化.下面可以看到綁定的寫法非常優雅.
UI綁定模型
PersonModel * model = [[PersonModel alloc]init]; model = self.dataArray.firstObject; RAC(self.lb_name,text)=RACObserve(model, name); //這里不能使用基本數據類型,RAC中傳遞的都是id類型,使用基本類型會崩潰,所以使用map方法對返回值進行了更替 RAC(self.lb_age,text)=[RACObserve(model, age) map:^id(id value) { return [value description]; }];
屏幕快照
這樣做的好處非常明顯:
UI與業務做了分離,同時方便了對邏輯層進行單元測試
分工更為明確,方便對不同能力的工程師進行指派任務,當然我個人認為是存在弊端的.
提高了View的復用性
屏幕快照
組件化開發
以前理解的mvvm通過這種組件化也達到了拆分功能與模塊的目的,但個人個人感覺耦合性有時還是不低,美團的做法是寫一個總線VM,同等級的VM之間讓他們的直接通信變成通過總線進行間接通信.這樣就能夠很好地解決組件VM與組件VM之間的耦合問題.順帶一提,組件VM與總線之間的通信是依靠RACSubject來進行的.
MVVM + RAC這種開發模式
MVVM使用并不需要RAC這個框架,但是RAC卻是最好的實現工具.我們一般使用MVVM一般在VM中會留有一些接口,用來返回數據,可是返回回來要賦值等并不優雅,而RAC可以通過綁定進行優雅的書寫,同時它的三種傳遞信號的方式可以涵蓋當前幾乎所有的事件形勢:繼續,錯誤,完成.同時他可以替代iOS幾乎所有的事件,能達到代碼高聚合的目的.RAC產生的信號我們是可以對他進行處理的,諸如過濾,依賴等等,這對有些業務是非常具有幫助性的.當然這個框架學習成本比較高,在項目中推行需要謹慎.
