mvc、mvp和mvvm

 

一、MVC

设计图:

 

可能由于MVP、MVVM的兴起,MVC在android中的应用变得越来越少了,但MVC是基础,理解好MVC才能更好的理解MVP,MVVM。因为后两种都是基于MVC发展而来的。

1.MVC,全称Model-View-Controller,即模型-视图-控制器。 具体如下:

  • View:对应于布局文件
  • Model:业务逻辑和实体模型
  • Controllor:对应于Activity

但是View对应于布局文件,其实能做的事情特别少,实际上关于该布局文件中的数据绑定的操作,事件处理的代码都在Activity中,造成了Activity既像View又像Controller,使得Activity变得臃肿。

2.MVC总结

  • 具有一定的分层,model彻底解耦,controller和view并没有解耦
  • 层与层之间的交互尽量使用回调或者去使用消息机制去完成,尽量避免直接持有
  • controller和view在android中无法做到彻底分离,但在代码逻辑层面一定要分清
  • 业务逻辑被放置在model层,能够更好的复用和修改增加业务

3.存在问题

  • M层和V层直接打交道,导致两层耦合度高
  • 因为几乎所有逻辑都在C层,导致C层特别臃肿

 

而当将架构改为MVP以后,Presenter的出现,将Actvity视为View层,Presenter负责完成View层与Model层的交互。现在是这样的:

二、MVP

MVP正是基于MVC的基础发展而来的。两个之间的关系也是源远流长,唯一的差别是Model和View之间不进行通讯,都是通过Presenter完成。从理论上去除了V和M的耦合。

1.MVP,全称 Model-View-Presenter,即模型-视图-层现器。

  • View 对应于Activity,负责View的绘制以及与用户交互
  • Model 依然是业务逻辑和实体模型
  • Presenter 负责完成View于Model间的交互

MVP模式通过Presenter实现数据和视图之间的交互,简化了Activity的职责。同时即避免了View和Model的直接联系,又通过Presenter实现两者之间的沟通。

总结:MVP模式减少了Activity的职责,简化了Activity中的代码,将复杂的逻辑代码提取到了Presenter中进行处理,模块职责划分明显,层次清晰。与之对应的好处就是,耦合度更低,更方便的进行测试。

通过中间层Preseter实现了Model和View的完全解耦。MVP彻底解决了MVC中View和Controller傻傻分不清楚的问题,但是随着业务逻辑的增加,一个页面可能会非常复杂,UI的改变是非常多,会有非常多的case,这样就会造成View的接口会很庞大,P会更臃肿。

 

MVC和MVP的区别

这里主要说他们的不同点:

1、Presenter与Controller都扮演了逻辑层的角色,但是Presenter层的功能相对更复杂,因为他负责和View的双向交互,Controller只是单向的中介。因为Presenter是从View层抽离出来的,通常和View是一对一的关系,而Controller是面向业务的,往往是单例模式或者提供静态方法。

2、MVP中View和Model是不能进行通信的,虽然加重了P层的负担,但是有利于维护View层和Model层,如果条件允许,我们还可以对Presenter进一步拆分,来弥补Presenter负担过重的问题。

3、MVC中View和Model层可以直接交互,虽然方便了两者之间的交互,但是耦合性相对较高。

 

 

三、MVVM

MVP中我们说过随着业务逻辑的增加,UI的改变多的情况下,会有非常多的跟UI相关的case,这样就会造成View的接口会很庞大。而MVVM就解决了这个问题,通过双向绑定的机制,实现数据和UI内容,只要想改其中一方,另一方都能够及时更新的一种设计理念,这样就省去了很多在View层中写很多case的情况,只需要改变数据就行。 先看下MVVM设计图:

mvvm.png

一般情况下就这两种情况,这看起来跟MVP好像没啥差别,其实区别还是挺大的,在MVP中View和presenter要相互持有,方便调用对方,而在MVP中 View和ViewModel通过Binding进行关联,他们之前的关联处理通过DataBinding完成。
 
MVVM 总结

看起来MVVM很好的解决了MVC和MVP的不足,但是由于数据和视图的双向绑定,导致出现问题时不太好定位来源,有可能数据问题导致,也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel、LiveData、DataBinding去实现MVVM

 
 
总结:如何选择
  • 如果项目简单,没什么复杂性,未来改动也不大的话,那就不要用设计模式或者架构方法,只需要将每个模块封装好,方便调用即可,不要为了使用设计模式或架构方法而使用。
  • 对于偏向展示型的app,绝大多数业务逻辑都在后端,app主要功能就是展示数据,交互等,建议使用mvvm。
  • 对于工具类或者需要写很多业务逻辑app,使用mvp或者mvvm都可。
  • 如果想通过一个项目去学习架构和设计模式,建议用MVC然后在此基础上慢慢挖掘改进。最后你可能发现,改进的最终结果可能就变成了mvp,mvvm。

 

posted @ 2019-04-26 01:03  Ivo-oo  阅读(577)  评论(0编辑  收藏  举报