MVC/MVP/MVVM总结

MVC/MVP/MVVM总结

mvc/mvp/mvvm概要

mvc/mvp/mvvm这三者的概念可以去其他地方脑补， 目前android/web/IOS开发都遵循着其中的一个框架或架构，各有各的优缺点，至于说那个真的好要看具体业务要求。

mvc

首先来说说MVC吧！MVC这种架构模式源于服务端的开发，在服务端MVC这种叫做三层架构。M model层也就是数据层，V view展示层即web页面，C controller层逻辑控制层，在服务端这种分层结构可以很好的将数据库、服务逻辑、页面展示三层分开，但是在前端，特别是移动前端这种MVC架构就变的很模糊了，究其原因有多方面：

1. 前端业务逻辑的复杂性比不了服务端
2. 前端与后端的侧重点不同，前端侧重UI，后端侧重业务逻辑
3. 前后端框架的发展不同，后端有专门处理M层的框架例如hibernate，Controlle层spring等等，而前端可能受知识的限制，本人并没有发现这种界限很明确的框架
4. 整个业界关注度不同，至于后面为什么出现了MVP/MVVM的问题，是因为移动端受业务的限制变的越来越臃肿，后期产生了很多代码屎山，本人就曾遇到过，这种屎山铲不掉越弄越复杂
5. 其他原因，仔细想想的话，真的会有许许多多原因。

可能现在还有很多的前端项目组都在延续着MVC模式吧，当然并不是MVC模式不好，而是要区分业务场景，如果业务不多，逻辑简单，个人觉得MVC真的好，可以省很多的事情和时间，但是如果业务多而且复杂，MVC就容易产生很多问题，而且V和C傻傻分不清，当然这要看前端开发者如何厘清架构

mvp

MVP是目前移动前端比较火的一个架构模式，是从MVC模式发展而来的，主要目的是减少View与model层相互逻辑耦合过高的情况，比如杂家从事的Android移动前端，Activity即包含View，又包含Model的处理逻辑，同样还包含View与model的交互逻辑。MVP体现了接口编程的思想，这种模式在C端实现比较容易，在配合上比较流行的Rxjava+Retrofix来控制服务与Model逻辑，简直不要不要的。那MVP模式大概是个啥样呢？M model层即实体，V view层即页面展示，P presenter层即页面与数据交换逻辑实现层。通过定义IView接口，IPresenter接口，封装相应的重复逻辑，让P控制服务的请求并处理Model逻辑，View展示相应的Model数据，这只是一个大概，具体后面会弄一个MVP的具体例子。同样可以去看看Google对于MVP的实现 Google。同样的其实MVP也是有不少的诟病：

1. 对于View和Present的理解，每一个开发者都有自己的一套，比较成熟的实现模型比较少
2. 对于封装MVP架构模式的开发者需要一定的认知，不然实现的MVP还是MVC，而且基础逻辑更复杂化
3. MVP并非真的完全解耦了View与Model的耦合，在一定程度上View还是会直接控制Model，不然怎么会有后面的MVVM呢？

当然，MVP的好处对于移动前端业务逻辑的开发真的提升了很多，而且不容易产生屎山。可能大家觉得Web端好像没怎么提到MVP，的确现在H5的发展太快了，框架层出不穷，好像直接就跳到了MVVM，所以Web端更多的是MVVM这种架构模式

mvvm

mvvm是同样目前前端开发比较火的一个架构模式，是从MVP模式发展而来的，主要目的还是进一步是减少View与model层相互逻辑耦的情况。MVVM实现更多的体现在框架的使用上，这种模式的基本理念就是将View和Model通过框架进行单向或者双向绑定，只要相应的数据有变化即可反应到绑定的View或者Model上。同样可以去看看Google对于MVVM的实现 Google。MVVM其实并没有啥可以说的，毕竟只要跟随框架介绍的走就OK了。同样MVVM的问题：

1. 需要对框架了解
2. 缺少灵活性，对问题分析存在一定难度
3. 对注解要一定的了解，不然很多问题一旦产生很难定位

以上见解都是围绕android或者web端来理解，对于IOS了解的还是比较少。后面再具体介绍下MVP与MVVM的实现

本作品采用知识共享署名 4.0 国际许可协议进行许可。