架构(上)

一：MVC: Modal View Controller（模型／视图／控制器）

1.Model 和 View 永远不能相互通信，只能通过 Controller 传递

2.Controller 可以直接与 Model 对话（读写调用 Model），Model 通过 Notification 和 KVO 机制与 Controller 间接通信。

3.Controller 可以直接与 View 对话，通过 outlet，直接操作 View，outlet 直接对应到 View 中的控件，View 通过 action 向 Controller 报告事件的发生(如用户 Touch 我了)。Controller 是 View 的直接数据源（数据很可能是 Controller 从 Model 中取得并经过加工了）。Controller 是 View 的代理（delegate)，以同步 View 与 Controller。

MVC思维导图

MVC自身不足

1）MVC 在现实应用中的不足：

在 MVC 模式中 view 将用户交互通知给控制器。view 的控制器通过更新 Model 来反应状态的改变。Model（通常使用 Key-Value-Observation）通知控制器来更新他们负责的 view。 

View 上面显示什么东西，取决于 Model,只要 Model 数据改了，View 的显示状态会跟着更改,Controller 负责初始化 Model，并将 Model 传递给 View 去解析展示

2）愈发笨重的 Controller：（UI更新，业务逻辑，网络）

3）太过于轻量级的 Model

4）遗失的网络逻辑：

5）较差的可测试性：

 二:MVP：Modal View Presenter（模型 视图 协调器）

MVP即Modal View Presenter（模型 视图 协调器），MVP实现了Cocoa的MVC的愿景。MVP的协调器Presenter并没有对ViewController的声明周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。

MVC和MVP的区别就是，在MVP中M和V没有直接通信。

1）MVP模式下的三个特性的分析：

任务均摊 -- 我们将最主要的任务划分到 Presenter 和 Model，而 View 的功能较少；

可测试性 -- 非常好，由于一个功能简单的 View 层，所以测试大多数业务逻辑也变得简单；

易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却非常清晰。

1、Model 层应该不仅仅是创建一个数据对象，还应该包含网络请求，以及数据 SQLite 的 CRUD 操作。一般可以将数据对象是否需要缓存设计成一个字段 isCache，或者针对整个项目设计一个开存储关，决定整个项目是否需要数据缓存。

2、View 层比较简单明，就是 View 的一些封装、重用。在一款精心设计过的 App 里面，应该有很多 View 是可以封装重用的。

3、Presenter 层并不涉及数据对象的网络请求和 SQLite 操作，只是 Model 层和 View 层的一个桥梁。Presenter 层就不至于太臃肿，容易看懂。

4）MVP的优势

模型与视图完全分离，我们可以修改视图而不影响模型

可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部

我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。

如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

5）MVP的问题

由于对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁。

还有一点你需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的 联系过于紧密。一旦视图需要变更，那么 Presenter也需要变更了

三:MVVM:Model View ViewModel(模型，视图，视图模型)

MVVM+RN 数据双向绑定

在 MVVM 中他的设计思路和 MVC 很像。它正式规范了视图和控制器紧耦合的性质，并引入新的组件 ViewModel。此外，它还有像监管版本的 MVP 那样的绑定功能，但这个绑定不是在 View 和 Model 之间而是在 View 和 ViewModel 之间。

1）MVVM 模式下的三个特性的分析：

任务均摊 -- MVVM 的 View 要比 MVP 中的 View 承担的责任多。因为前者通过 ViewModel 的设置绑定来更新状态，而后者只监听 Presenter 的事件但并不会对自己有什么更新。

可测试性 -- ViewModel 不知道关于 View 的任何事情，这允许我们可以轻易的测试 ViewModel 

易用性 -- 在实际开发中必须把 View 中的事件指向 Presenter 并且手动的来更新 View，如果使用绑定的话，MVVM 代码量将会小的多。

MVVM思维导图

1.在 MVVM 里，view 和 view controller 正式联系在一起，我们把它们视为一个组件。视图 view 仍然不能直接引用模型 Model，当然 controller 也不能。相反，他们引用视图模型 View Model。

2.View Model 是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入 View Model，那就是任何视图本身的引用 

3.由于展示逻辑（presentation logic）放在了 View Model 中（比如 Model 的值映射到一个格式化的字符串），视图控制器本身就会不再臃肿。当然你开始使用 MVVM 的最好方式时可以先将一小部分逻辑放入视图模型，然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。

使用 MVVM 会轻微的增加代码量，但总体上减少了代码的复杂性。

备注：基本逻辑View--->ViewModel/Present(网络逻辑)--->Model