MVP的前身 — MVC
关于MVP,就必须要先介绍一下它的前辈MVC,因为MVP是基于MVC的基础发展而来的
MVC,全称Model-View-Controller,即模型-视图-控制器。
View:对应于布局文件
Model:业务逻辑和实体模型
Controllor:对应于Activity
但是View对应于布局文件,其实能做的事情很少,关于该布局文件中的数据操作和事件处理的代码都在Activity中,造成了Activity既像View又像Controller,使得Activity变得臃肿
MVP与MVC的区别
MVC中是允许Model和View进行交互的,而在MVP中,Model与View之间的交互由Presenter完成,Presenter与View之间的交互是通过接口的,MVC中V对应的是布局文件,MVP中V对应的是Activity
MVP
MVP模式通过Presenter实现数据和视图之间的交互,简化了Activity的职责,同时避免了View和Model的直接联系,又通过Presenter实现两者之间的沟通
View 对应于Activity,负责View的绘制以及与用户交互
Model 业务逻辑和实体模型
Presenter 负责完成View于Model间的交互
优点:解决了MVC中Contreller与View过度耦合的缺点,职责划分明显,更加易于维护
缺点:接口数量多,随着项目复杂度的提升,Presenter层将越来越臃肿
MVP核心流程
使用Presenter作为View与Model之间的桥梁,当View层某个界面需要展示某些数据的时候,首先会调用Presenter的引用,然后Presenter层会调用Model层请求数据,当Model层数据加载成功之后,Presenter层再调用View层的接口将加载后的数据展示给用户
Concacts类
此为契约类,将View、Presenter 进行约束管理,方便后期类的查找和维护
class MainConcacts {
interface IView {
// View层获取数据回调方法
fun onResultData(data: MsgBean?)
fun onResultFail(exp: String?)
}
interface IPresenter {
// View层向Presenter发送请求方法
fun requestData(context: Context?)
}
}
Presenter层
class MainPresenter(private var iView: MainConcacts.IView) : MainConcacts.IPresenter {
//此写法可以弱化Model的作用,这里的网络请求就是Modle,可以省略Modle文件
override fun requestData(context: Context?) {
RxHttp.postForm(MainApi.URL)
.add("ID", id)
.add("index", index)
.add("size", size)
.asClass(MsgBean::class.java)
.observeOn(AndroidSchedulers.mainThread())
.subscribe({ msg: MsgBean? ->
iView.onResultData(msg)
}) { throwable: Throwable? ->
iView.onResultFail(throwable?.message)
}
}
}
View层
class MainActivity : AppCompatActivity(), MainConcacts.IView {
private val mainPresenter: MainPresenter by lazy {
MainPresenter(this)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
mainPresenter.requestData(this)
}
override fun onResultData(data: MsgBean?) {
text.text = data?.data?.get(0)?.descript
}
override fun onResultFail(exp: String?) {
Toast.makeText(this, exp, Toast.LENGTH_SHORT).show()
}
}