之前对于MVC和MVP真的傻傻分不清,下面代领大家10分钟来理解MVP
MVC: model、view、controller
MVP:model、view、presenter
需求
还是以参考文章为例子,假如我们要做一个简单的下载器,有下载功能,进度显示、下载结果回调等功能
MVP 模式所做的事情很简单,就是将业务逻辑和视图逻辑抽象到接口中
step 1:梳理业务具体要实现的功能,细化每个模块的职责
model: 负责发起网络请求,返回下载数据
view: 负责更新下载进度、UI提示用户下载成功或者失败等
presenter: 两者之间的桥梁,调度功能
step 2:定义Model,View,Presenter 接口
针对每一层都增加一个接口类,比如IDownloadModel、IDownloadView, IDowndownPresenter.
step 3:具体实现
|
|
|
|
梳理:
每个模块都需要实现自己的接口IDownloadView等Ixxx。
处理关于构造里面的关联情况,DownloadPresenter的构造方法中,同时实例化了Model和View,这样Presenter中就同时包含了两者;这样;在Presenter具体实现中,业务相关的操作由Model去完成(例如download),视图相关的操作由View去完成(如setView等)。
- 数据处理完需要回调DownloadPresenter,所以需要注入IDownloadPresenter到model里面
- Presenter 作为桥梁的作用就这样体现出来了,巧妙的将View和Model的具体实现连接了起来。
总结
- 各部分之间的通信,都是双向的。
- View 与 Model 不发生联系,都通过 Presenter 传递。
- View 非常薄,不部署任何业务逻辑,称为”被动视图”(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
MVP Model,View,Presenter各司其职,互相搭配,实现了解耦,完全解放了Activity(或者是Fragment)。这就是MVP 的优势,代码结构更加清晰。可以这样说,同一个模块的实现,甚至允许几个人分工完成;假设有一个非常复杂的Activity,如果使用MVP 的模式开发;那么这个时候,定义好MVP的接口之后,就可以有人专门去做Model,另一个人专门去做View;再由一个人写Presenter的代码,当然这需要极强的代码规范和协作能力;但这在传统的MVC模式中根本是无法想象的,所有的东西都在一个类里,两个人一起改。
参考:
http://www.jianshu.com/p/760b4a1ab5b5
http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html
https://github.com/googlesamples/android-architecture