前言
以前對mvvm的理解僅僅是將控制器的一些業務邏輯以及一些網路請求等與UI無關的東西儘量放到vm中去做,自從看完了樑士興與臧成威大大的演講對其有了更進一步的認識.以下圖片均來自樑士興與臧成威大大的演講PPT.
業務發展所面臨的挑戰
隨著美團的發展,他的業務也變得複雜起來,主要面臨的挑戰就是程式碼的可複用性降低,放大了業務的差異性,以及在複雜的業務需求下,對不同能力的工程師進行分配任務缺少指導原則.美團的做法是從拆做起,改善架構設計,提升程式碼複用.
解決方法
對架構進行了重新設計,引入了MVVM架構與響應式程式設計,通過將業務邏輯拆分到vm中,這樣初中級的工程師可以去寫UI,而富有經驗的工程師負責去寫VM(業務邏輯),同時將業務邏輯抽取出來也可以提高程式碼的複用性.但我個人認為這裡有一個弊端,就是長期從事單一的方向編寫對工程師的個人成長並沒有什麼好處.
繫結
我們可以將cell的顯示的資料放入到VM中,通過RAC的繫結,將cell的元素與VM暴露出來的屬性繫結在一起,這樣當資料變化的時候,我們並不需要重新整理cell就可以做到動態的變化.下面可以看到繫結的寫法非常優雅.
UI繫結模型
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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產生的訊號我們是可以對他進行處理的,諸如過濾,依賴等等,這對有些業務是非常具有幫助性的.當然這個框架學習成本比較高,在專案中推行需要謹慎.
RAC的實現
RAC的實現原理並不是通過KVO來實現的,而是通過BIND來實現的,它使用大量的block來實現了OC函式化得目的,SWIFT是使用閉包來進行的,下面上一段Noah前輩的程式碼,程式碼本身並不難,重要的是這種思想吧.對了這位前輩在找工作,在廣州的小夥伴如有用人需求可以私信我啊.?
