关于阅读RAC相关blog的总结

旧文新读

关于RAC目前已经有很多的公司在使用，但是从入门到熟悉还有很多坑需要跳，尤其是刚接触，但是没有任何实战经验的。以下是我看别人的blog的总结 唐巧的blog

1. 在团队如何推广RAC

不断的review + 熟练的人指导

2. 对人才的培养
   有道再有术 --->先灌输思想，在传授技术
3. RAC使用的场景
   一、UI 操作，连续的动作与动画部分，例如某些控件跟随滚动。
   二、网络库，因为数据是在一定时间后才返回回来，不是立刻就返回的。
   三、刷新的业务逻辑，当触发点是多种的时候，业务往往会变得很复杂，用 delegate、notification、observe 混用，难以统一。这时用 RAC 可以保证上层的高度一致性，从而简化逻辑上分层。
   只要有通知的业务逻辑，RAC 都方便有效化解。
   用 RACSubject + RACComand 来简化和统一应用的错误处理逻辑

雷纯锋：概括的说，应该就是统一所有异步事件吧。
不适用的场景，与时间无关的，需要积极求解的计算，例如视图的单次渲染

4. 调试
   关于调试，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 的某个获取数据的方法。

1. ViewController 尽量不涉及业务逻辑，让 ViewModel 去做这些事情。
2. ViewController 只是一个中间人，接收 View 的事件、调用
3. ViewModel 的方法、响应 ViewModel 的变化。
4. ViewModel 不能包含 View，不然就跟 View 产生了耦合，不方便复用和测试。
5. ViewModel 之间可以有依赖。
6. ViewModel 避免过于臃肿，不然维护起来也是个问题。

MVVM 并不复杂，跟 MVC 也是兼容的，只是多了一个 ViewModel 层，但就是这么一个小改动，就能让代码变得更加容易阅读和维护，不妨试一下吧。