先说一下架构中模式吧
参考 https://www.jianshu.com/p/856d3f7e1484
1.mvvm
我个人认为MVVM仅仅是一种思想，并不一定遵循已有的架构方案，其目的能做到将vc中的一些代码能单独的抽离出来就好了，那么VC包含什么呢，UI绘制，网络请求，数据处理，事件响应，代理实现，逻辑刷新，由此可见这里面能抽出来的只有UI绘制，网络请求，因为逻辑交互最好写在VC，便于VC和VC之间的通信交互和跳转等事件响应。那么View已经负责了UI绘制和封装，那么数据和网络请求怎么单独给一个封装呢，此时就是所谓的viewModel，那么这里可以做那些东西呢。1.既然把数据放在这里，那么数组最终是要传递给VC去使用来处理VC中的逻辑的，那么数据怎么传递呢。1.block 2.代理。比如把tableView的代理全部拿到这一层的model，之前我做过一个完整功能的购物车模块，可想而知这里tableView的数据源和代理必然会有很多复杂的逻辑以及数据交互，为了VC代码释压，把网络请求处理，自己定义代理和方法在单独文件去实现，VC去维护这些代理，然后单开另一个继承NSObject的文件去处理tableView的所有代理。这样实际也是MVVM的思想实现。
其核心思想就是解决VC中能抽离出来的所有层面
但是不可否认缺点
1.代理都是自己写的，命名随意，如果遇到下一个模块，无法复用，即便复用，翻译过来的语义和业务不对应
2.VC是只做到了把所有文件通信起来，代码少了，但是其他文件增多了，文件中的代码量并不少，也不精简
3.阅读性提高了，能读懂，但是不方便数据来往传递，依靠各种代理去实现
所以MVVM这时候有一个配合使用的东西，叫做RAC
rac是标准化的东西，是收发信号来处理数据甚至事件的东西，不局限在数据之间的处理，还能操作事件之间的信号响应。有效的精简了OC原有的代码书写样式
而且rac方法都是统一的，使用也是标准了，不需要自己各种代理去自己命名，
所以MVVM+rac模式现在是一种能够从VC中剥离出数据处理网络请求，UI绘制，事件信号传递的一个东西
网友评论