旧文新读
关于RAC目前已经有很多的公司在使用，但是从入门到熟悉还有很多坑需要跳，尤其是刚接触，但是没有任何实战经验的。以下是我看别人的blog的总结 唐巧的blog
- 在团队如何推广RAC
不断的review + 熟练的人指导
- 对人才的培养
有道再有术 --->先灌输思想，在传授技术 - RAC使用的场景
一、UI 操作，连续的动作与动画部分，例如某些控件跟随滚动。
二、网络库，因为数据是在一定时间后才返回回来，不是立刻就返回的。
三、刷新的业务逻辑，当触发点是多种的时候，业务往往会变得很复杂，用 delegate、notification、observe 混用，难以统一。这时用 RAC 可以保证上层的高度一致性，从而简化逻辑上分层。
只要有通知的业务逻辑，RAC 都方便有效化解。
用 RACSubject + RACComand 来简化和统一应用的错误处理逻辑
雷纯锋：概括的说，应该就是统一所有异步事件吧。
不适用的场景，与时间无关的，需要积极求解的计算，例如视图的单次渲染
- 调试
关于调试，RAC 源码下有 instruments 的两个插件，方便大家使用。
signalEvents 这个可以看到流动的信号的发出情况，对于时序的问题可以比较好的解决。
diposable 可以检查信号的 disposable 是否正常
MVVM tips
MVVM 是 MVC 模式的一种演进，它主要解决了 ViewController 过于臃肿带来的不易维护和测试的问题。其中 ViewModel 的主要职责是处理数据业务逻辑并提供 View 所需的数据，这样 VC 就不用关心业务，自然也就瘦了下来。ViewModel 只关心业务数据不关心 View，所以不会与 View 产生耦合，也就更方便进行单元测试。
View 是一个壳，它所呈现的内容都需要由 ViewModel 来提供，而 View 又不与 ViewModel 直接沟通，这时就需要 ViewController 来做中间的协调者,另外还要协调VC间的交互。
ViewController 持有 View 和 ViewModel，当 VC 初始化时，会让 ViewModel 去取数据，简单来说就是调用 VM 的某个获取数据的方法。
- ViewController 尽量不涉及业务逻辑，让 ViewModel 去做这些事情。
- ViewController 只是一个中间人，接收 View 的事件、调用
- ViewModel 的方法、响应 ViewModel 的变化。
- ViewModel 不能包含 View，不然就跟 View 产生了耦合，不方便复用和测试。
- ViewModel 之间可以有依赖。
- ViewModel 避免过于臃肿，不然维护起来也是个问题。
MVVM 并不复杂，跟 MVC 也是兼容的，只是多了一个 ViewModel 层，但就是这么一个小改动，就能让代码变得更加容易阅读和维护，不妨试一下吧。
网友评论