前言
以前对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产生的信号我们是可以对他进行处理的,诸如过滤,依赖等等,这对有些业务是非常具有帮助性的.当然这个框架学习成本比较高,在项目中推行需要谨慎.