Android框架中的MVC、MVP、MVVM设计思想

框架和设计模式的异同
框架并非设计模式，框架中包含有设计模式，对框架而言是对相同行为代码的重用，而设计模式是对相同结构代码的重用。框架适用于系统模块开发，而设计模式适用于功能模块开发。框架是大智慧，对系统软件设计进行分工，明确各自职能； 设计模式是小技巧，对具体问题提出应对策略，提高代码复用率，降低系统耦合。

框架的适用性
并不是开发一个系统就需要使用框架，框架所做的事是把模块分离开发，让专业人员做专业的事，比如MVC框架，视图层由前端人员开发，后端工程师则专注业务逻辑开发。但这毫无疑问分离开来会增加文件数量，而且调试也需要进一步沟通，如果手上的是一个小项目，仅仅百行代码如果用了MVC那会适得其反，但如果是商业化的大项目，使用框架就如鱼得水。

图示

由3者的图示我们总结下：

• MVC：View直接访问Model，3者构成回路，耦合度大
• MVP：View与Model解耦，通过中介者Presenter简介请求访问
• MVVM：与MVP很相似，View与Model 的双向绑定，不需要中介者，View一经改变立刻通知到Model

---

MVC
经典的设计框架，而且Android中也已经预先为我们实现好了的：

1. Model–本地实体数据文件、或其他数据体
2. View–XML文件（layout显示相关部分）
3. Controller–Activity组件

具体实现就不多叙述了，日常开发中我们遵循的基础就是系统搭建好的这个MVC框架，我们基本不会刻意去修改实现。

优点：经典的框架，业务逻辑集中在Controller，当需要逻辑变更不需要动Model和View只需要替换Controller即可。
缺点：测试困难，View依赖Model存在，耦合度大，不易剥离

MVP
MVP可以是称为是MVC的升级版，MVC的模式虽然很经典，但进步总是建立在修改的基础上的。MVC的不足之处是无经验的开发人员会将Model与View混为一谈，业务逻辑和数据存取出现在同一Activity中并不是空穴来风，引发类型膨胀的问题。如果产品升级需要重新开发UI，这时候就牵扯到数据逻辑的开发人员。
所以MVP就是升级来解决这个问题的。

1. Model–数据的存取
2. View–用户界面（xml文件显示相关）
3. Presenter–中介者（View和Model沟通的桥梁）

优点：解耦View与Model的联系，便于测试，Controller不依赖View环境测试，View针对接口存在，易于剥离
缺点：Presenter中存在大量View、Model同步的问题

MVVM

1. Model–数据存取
2. View–用户界面
3. ViewModel–View、Model视图绑定机制

MVVM与MVP的区别是，让View和Model双向绑定，实现类似于观察者模式，View改变则通知Model相应改变，相反Model改变也通知View改变。

优点：解决View–Model手动同步问题，简化测试操作，减小同步更新以及后续操作
缺点：非复杂项目不建议采用，不适用于视图少的项目，维护成本较高

总结
MVC–>MVP–>MVVM，逐步升级，后者改善前者的不足，把缺点变成优点，但并不是说MVVM就是最终最好的，解决上一代不足的问题后肯定会有其他负面影响的，实际开发中要根据实质情况，选择需要用哪一个。