ReactiveCocoa理解笔记（1）
之前做项目用到了ReactiveCocoa，当时只是知其然，不知所以然，很多都是根据用法示例找图画瓢。最近正好空闲下来，抽些时间理解ReactiveCocoa框架，整理一下之前的用法，以便朋友相互学习。
<p><code>该文章适合有一定iOS开发基础的伙伴，如果你是一位iOS新手，那么该文章现在不适合你，可以先收藏，以后再消化。</p></code>
什么是ReactiveCocoa？
ReactiveCocoa（其简称为RAC）是由Github开源的一个应用于iOS和OS X开发的新框架。RAC具有函数式编程和响应式编程的特性。它主要吸取了.Net的 Reactive Extensions的设计和实现。
ReactiveCocoa结合了几种编程风格：
函数式编程（Functional Programming）：使用高阶函数，例如函数用其他函数作为参数。
响应式编程（Reactive Programming）：关注于数据流和变化传播。
所以，你可能听说过ReactiveCocoa被描述为函数响应式编程（FRP）框架。编程范式是个很范的概念，不作为本篇的主题。
为何使用?
任何一个软件工程师知道MVC，它意思是Model-View-Controller, 是项目开发中公认的代码组织模式。 在 iOS 开发中它还有着第二种含义: Massive-View-Controller(重量级视图控制器)，它没有指出网络代码、数据组织代码所在的层次，导致Controller负责太多的事情，代码变得臃肿复杂。每当碰到这类代码需要需改的时候，程序员脑中都会想过重构、解耦代码的想法，然而因为时间、风险等等原因，大家只能想想了。总的来说, 很多iOS 开发者已经意识到: 需要给视图控制器（UiViewController）瘦身, 并进一步分离业务。
传统MVC模式工程主要会出现2个问题：
- iOS开发过程中，状态依赖（KVO）实现方式复杂，实用性较小
- UiViewController比较复杂，代码耦合性较高
很多开发者都会遇到上面的问题，这时我们需要思考如何解决这类问题，寻找新的方案?
MVVM
于是MVVM流行起来, 它代表Model-View-ViewModel, 它主要解决Controller层复杂性高、耦合性高的问题，帮助我们重新组织工程代码。我将要在这里展示的 MVVM 的风格, 它跟 MVC 十分兼容，只要我们将 MVC中Controller层的代码分开处理即可完成。
<p><code>我不会抬高MVVM、贬低MVC, 因为他们各有优缺，不会相互取代，同时还可相互兼容。 MVVM模式也是我第一次使用，我将会关注如何用它进行 iOS开发。</p></code>
MVVM的定义
- Model 在 MVVM 中没有真正的变化。 取决于你的偏好, 你的 model 可能会或可能不会封装一些额外的业务逻辑工作。我更倾向于把它当做一个容纳表现数据-模型对象信息的结构体, 并在一个单独的管理类中维护的创建/管理模型的统一逻辑。
-
View包含实际 UI 本身(可以是 UIView 代码, xib，storyboard), 可以包含视图特定的逻辑, 或用户操作的反馈。在 iOS 中这不仅需要 UIView 代码和那些文件, 还包括部分UIViewController。
-
View-Model 这个术语本身比较疑惑, 因为它混搭了前面两个我们已知的术语, 但却是完全不同的东西。 它不是传统模型层和视图层的结合，它的职责之一就是作为一个中间层连接模型层（Model）;它还承担收集、解析和转换数据的责任。这将这留给了 view (controller) 一个更加清晰明确的任务:承载View层视图，组织展示由 view-model 提供的数据。
MVC
MVVM
对比两种模式，可以简单的认为MVVM比MVC多了一个中间层View-Model ，可以理解为: 我们将Controller中的网络请求代码、数据管理代码和部分业务代码移动到了它拥有的View-Model 中。这样UIViewController 就能够专注的负责View的管理、界面流程跳转。
尽管我们的代码并有没有减少，代码层次增加了，但是Controller由臃肿变得简洁，由复杂变得清晰。针对功能单一的层次代码，我们易于理解，也方便进行单元测试。总的来说，MVVM模式更加适合iOS移动APP工程开发。
在下章，我将说明：
- MVVM和ReactiveCocoa的关系
- 为什么要使用ReactiveCocoa
- ReactiveCocoa的基本用法
