架构方式解决的痛点是工程中的文件/类之间的关系，通过对变量、方法的分离让整体的文件结构管理起来更有章法（高内聚、低耦合）
-阮一峰-MVC，MVP 和 MVVM 的图示
=浅谈 MVC、MVP 和 MVVM 架构模式
+第一章第一节：MVX模式是什么？MVC、MVP、MVVM详解
MVC 特点：1. View传送指令到Controller
- Controller完成指令后要求Model改状态
- Model将新数据发送给View，用户有反馈所有通信单向
MVVM 特点：1. 各部分间通信是双向的 - 采用双向绑定： View的变动，自动反映在ViewModel，反之亦然
1.mvc:数据、View、Activity，View 将操作反馈给 Activity，Activitiy 去获取数据，数据通过观察
者模式刷新给 View。循环依赖
o 1.Activity 重，很难单元测试
o 2.View 和 Model 耦合严重
2.mvp:数据、View、Presenter，View 将操作给 Presenter，Presenter 去获取数据，数据获取好了返
回给 Presenter，Presenter 去刷新 View。PV，PM 双向依赖
o 1.接口爆炸
o 2.Presenter 很重
3.mvvm:数据、View、ViewModel，View 将操作给 ViewModel，ViewModel 去获取数据，数据和
界面绑定了，数据更新界面更新。
o 1.viewModel 的业务逻辑可以单独拿来测试
o 2.一个 view 对应一个 viewModel 业务逻辑可以分离，不会出现全能类
o 3.数据和界面绑定了，不用写垃圾代码，但是复用起来不舒服
- 单元测试
- 文件数量、文件重量
- 业务上的分离，架构单元间的耦合
MVP，MVVM，MVC 解释和实践
MVC: 视图层(View) 对应于 xml 布局文件和 java 代码动态 view 部分
控制层(Controller) MVC 中 Android 的控制层是由 Activity 来承担的，
Activity 本来主要是作为初始化页面，展示数据的操作，但是因为 XML 视
图功能太弱，所以 Activity 既要负责视图的显示又要加入控制逻辑，承担
的功能过多。
模型层(Model) 针对业务模型，建立数据结构和相关的类，它主要负责网
络请求，数据库处理，I/O 的操作。
总结
具有一定的分层，model 彻底解耦，controller 和 view 并没有解耦 层与层之间
的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有 controller
和 view 在 android 中无法做到彻底分离，但在代码逻辑层面一定要分清 业务逻
辑被放置在 model 层，能够更好的复用和修改增加业务。
MVP
通过引入接口 BaseView，让相应的视图组件如 Activity，Fragment 去实现
BaseView，实现了视图层的独立，通过中间层 Preseter 实现了 Model 和 View
的完全解耦。MVP 彻底解决了 MVC 中 View 和 Controller 傻傻分不清楚的问题，
但是随着业务逻辑的增加，一个页面可能会非常复杂，UI 的改变是非常多，会
有非常多的 case，这样就会造成 View 的接口会很庞大。
MVVM
MVP 中我们说过随着业务逻辑的增加，UI 的改变多的情况下，会有非常多的跟
UI 相关的 case，这样就会造成 View 的接口会很庞大。而 MVVM 就解决了这个
问题，通过双向绑定的机制，实现数据和 UI 内容，只要想改其中一方，另一方
都能够及时更新的一种设计理念，这样就省去了很多在 View 层中写很多 case
的情况，只需要改变数据就行。
MVVM 与 DataBinding 的关系？
MVVM 是一种思想，DataBinding 是谷歌推出的方便实现 MVVM 的工具。
看起来 MVVM 很好的解决了 MVC 和 MVP 的不足，但是由于数据和视图的双向
绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻
辑中对视图属性的修改导致。如果项目中打算用 MVVM 的话可以考虑使用官方
的架构组件 ViewModel、LiveData、DataBinding 去实现 MVVM。
三者如何选择？
如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模
式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使
用设计模式或架构方法而使用。
对于偏向展示型的 app，绝大多数业务逻辑都在后端，app 主要功能就是
展示数据，交互等，建议使用 mvvm。
对于工具类或者需要写很多业务逻辑 app，使用 mvp 或者 mvvm 都可。
