MVC: Modal View Controller
软件架构的七大原则:开一单，结合迪丽热巴
1.开闭原则 ：对扩展开放，对修改关闭
2.依赖倒置原则 ：实现尽量依赖抽象，不依赖具体实现
3.单一职责原则 ：一个类，接口，方法职责尽量单一
4.接口隔离原则 ：客户端不应该依赖它不需要的接口，类之间的依赖关系应该建立在最小接口上
5.合成/聚合复用原则 ：尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的
6.迪米特法则（最小知道原则）：一个对象应该对其他对象保持最小的了解，尽量降低类与类之间的耦合
7.里氏替换原则：一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用弗雷的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变
不管我们选择何种架构模式，我们都是朝着代码的可扩展性、可维护性、复用性、可读性去的。我们最终的目的都是为了降低代码的耦合性，方便后续的修改、扩展和维护。
MVVM模式与MVC模式最大的特点并不是降低了VC中代码的臃肿，而是MVMM架构模式把业务逻辑统一到了VM中处理，方便单元测试和自动化测试。
MVC自身不足
1）MVC 在现实应用中的不足：
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 代码量将会小的多。
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
