MVC/MVP/MVVP区别
所谓的mvp,即是(model-处理业务逻辑(主要是数据读写,或者与后台通信(其实也是读写数据)),view-处理ui控件,presenter-主导器,操作model和view)
MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。其中M层处理数据,业务逻辑等;V层处理界面的显示结果;C层起到桥梁的作用,来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。
在Android开发中,比较流行的开发框架模式采用的是MVC框架模式,采用MVC模式的好处是便于UI界面部分的显示和业务逻辑,数据处理分开。那么Android项目中哪些代码来充当M,V,C角色呢?
- M层:适合做一些业务逻辑处理,比如数据库存取操作,网络操作,复杂的算法,耗时的任务等都在model层处理。
- V层:应用层中处理数据显示的部分,XML布局可以视为V层,显示Model层的数据结果。
- C层:在Android中,Activity处理用户交互问题,因此可以认为Activity是控制器,Activity读取V视图层的数据(eg.读取当前EditText控件的数据),控制用户输入(eg.EditText控件数据的输入),并向Model发送数据请求(eg.发起网络请求等)使用
MVC,把业务逻辑抽离到 Controller 中,让 View 层专注于显示 UI。
把Controller和View混在一起,有什么问题?
1.难以测试。
必须手动点击,使用各种自动化的测试工具。
2.代码难以重用。
UI是很难重用,因为要求总是不同。所以,导致重复的代码四处都是,维护麻烦。
MVC/MVP
View强依赖于Model是MVC的主要问题。由此导致很多控件都是根据业务定制,从Android的角度来看,原本可以由一个通用的layout就能实现的控件,由于要绑定实体模型,现在必须要自定义控件,这导致出现大量不必要的重复代码。因此有必要将View和Model进行解耦,而MVP的主要思想就是解耦View和Model。由此引入MVP就显得很自然。
MVP存在的问题:
尽管已经有了大量的应用,但不可否认该模式的还是存在一些问题,这些问题在携程的使用过程中也得到了体现。比如,上下文丢失问题,生命周期问题,内存泄露问题以及大量的自定义接口,回调链变长等问题。可以归纳为:
1.业务复杂时,可能使得Activity变成更加复杂,比如要实现N个IView,然后写更多个模版方法。
2.业务复杂时,各个角色之间通信会变得很冗长和复杂,回调链过长。
3.Presenter处理业务,让业务变得很分散,不能全局掌握业务,很难去回答某个业务究竟是在哪里处理的。
4.用Presenter替代Controller是一个危险的做法,可能出现内存泄漏,生命周期不同步,上下文丢失等问题。
2.使用MVP的好处
(1)MVP模式会解除View与Model的耦合,有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性,保证系统的整洁
性和灵活性。
(2)MVP模式可以分离显示层与逻辑层,它们之间通过接口进行通信,降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭
配不同的显示界面,因为它们之间并不依赖与具体,而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI,
使之具有更广泛的适用性,保证了灵活度。
3.MVP模式的三个角色
(1)Presenter – 交互中间人:Presenter主要作为沟通View与Model的桥梁,它从Model层检索数据后,返回给View层,使得View与Model之间没有耦合,也将业务逻辑从View角色上抽离出来。
(2)View – 用户界面:View通常是指Activity、Fragment或者某个View控件,它含有一个Presenter成员变量。通常View需要实现一个逻辑接口,将View上的操作转交给Presenter进行实现,最后,Presenter 调用View逻辑接口将结果返回给View元素。
(3)Model – 数据的存取:Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据,Model就像一个数据仓库。更直白的说,Model是封装了数据库DAO或者网络获取数据的角色,或者两种数据方式获取的集合。
View :是指显示数据并且和用户交互的层。在安卓中,它们可以是一个Activity,一个Fragment,一个android.view.View或者是一个Dialog。
Model :是数据源层。比如数据库接口或者远程服务器的api。
Presenter:是从Model中获取数据并提供给View的层,Presenter还负责处理后台任务
- M-Model : 业务逻辑和实体模型(biz/bean)
- V-View : 布局文件(XML)
- C-Controllor : 控制器(Activity)
- M-Model : 业务逻辑和实体模型(biz/bean)
- V-View : 布局文件(XML)和Activity
- P-Presenter : 完成View和Model的交互
1. 各部分之间的通信,都是双向的。
2. View 与 Model 不发生联系,都通过 Presenter 传递。
3. View 非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
- M-Model : 实体模型(biz/bean)
- V-View : 布局文件(XML)
- VM-ViewModel : binder所在之处,对外暴露出公共属性,View和Model的绑定器
从上图可以看出:MVC的耦合性还是较高的,View可以直接访问Model,导致3者之间构成了回路。所以两者的主要区别是,MVP
中View不能直接访问Model,需要通过Presenter发出请求,View与Model不能直接通信。
在MVP模式里,View只应该有简单的Set/Get的方法,用户用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容
许直接直接访问Model--这就是与MVC很大的不同之处。
2.与MVVM(Model-View-ViewModel)的区别
MVVM与MVP非常相似,唯一区别是View和Model进行双向绑定,两者之间有一方发生变化则会反应到另一方上。MVVM模式有点
像ListView与Adapter、数据集的关系,当数据集发生变化时,调用Adapter的notifyDataSetChanged之后View就直接更新,同时它们
之间又没有耦合,使得ListView变得更加灵活。
http://blog.csdn.net/shareus/article/details/51481308
http://blog.csdn.net/qq_17250009/article/details/51161074