生命不必每时每刻都要冲刺,低沉时就当是放一个悠长假期。 - 北川悦吏子/编剧
GitHub地址:ProjectPatternStudy
基本Android项目都采用MVC、MVP、MVVM架构,个人认为软件架构没有绝对的优劣之分,大家都各有利弊。
- 如果页面比较单一,采用MVC也未尝不可;
- 如果需要稳定性高,解耦性强就可以选用MVP,使M层与V层分离,结构更清晰;
- 如果想尝鲜(其实已经有段时间了),少写接口,高效,也可以使用MVVM;
阮一峰《MVC,MVP 和 MVVM 的图示》总结的非常简练,这里相当于扩展了一下,对于不太懂的人可能会用处更大。
MVP-databinding:是使用MVP架构,但是布局使用databinding设置值,也是行之有效的一种,也可以满足你的需求。
MVC
Model-View-Controller,最常见的软件架构之一。
- 视图(View):用户界面。
- 控制器(Controller):业务逻辑
- 模型(Model):数据保存
如Avtivity
里的一个点击事件:
|
|
如果一个页面比较简单,只有简单的几个操作,也不会经常去改可以使用此方式;如果页面逻辑比较复杂,接口请求都有好几个,那么不建议使用MVC,因为代码会全部堆积在一个Activity里面,会显得非常之冗余。
MVP
MVP 模式将 Controller 改名为 Presenter,同时改变了通信方向。
通过P层将Model层与View层解耦,同时P与V、P与M可以相互通信。
下面举个登录的例子:
|
|
|
|
|
|
用户点击登录,触发点击事件,然后通过P层userLoginPresenter
,调用登录的方法login()
,方法里面会通过Model层mUserBiz.login()
去做一些数据请求操作的处理,然后得到相应的数据返回。这里看到Model层的数据处理操作放在P层里,是不与V层直接交互的。
然后M层得到数据后回调,P层根据相应的数据,显示不同的UI,如toMainActivity
,showFailedError
等,这样V层只会出现一些基本的显示逻辑的处理。
MVVM
MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。
唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然。
|
|
|
|
|
|
可以看出,MVVM比MVP少了对应View的接口文件,这样更简洁了,而且,改变ViewModel里的值,则xml
文件对应的值也会对应改变。如果通过手动setText(),则ViewModel
里的值也会得到改变。通过这一层关系,我们可以通过数据去操控View
里的显示,所以才可以去除掉对应View的接口文件。
MVP-databinding
基本实现了MVC,MVP,MVVM后,我发现它们各自有各自的优缺点。
MVC:简单,单一页面可以实现。但是不利于复杂页面。
MVP:解耦,结构清晰。但文件较多,每一个页面基本要新建P层和V层的文件,同时还会有findViewById操作。
MVVM:解耦,结构相对清晰,文件相对MVP较少。但如果页面显示比较复杂,需要通过多个值去控制页面的显示,或者页面一个值的显示 要通过多种逻辑去处理得到结果,个人感觉还是不太适用。(其中的ViewModel与对应宿主的生命周期相同,从而内存泄漏问题比MVP处理较好这里先不做讨论)
MVP-databinding:
处理方式与MVP相同,只是使用了databinding的优势,databinding节省了类似findViewById和数据绑定的时间,从此代码里就没有findViewById和ButterKnife之类的代码了,而且也不会有通过多个值去控制页面的显示
这样不好操作的情况了。当然文件还是会多一些。
|
|
|
|
参考资料
- 张鸿洋:浅谈 MVP in Android
- 阮一峰: MVC,MVP 和 MVVM 的图示
- Jensen: Android中的MVC和MVP(分析+实例)
- CSDN: 认清Android框架 MVC,MVP和MVVM
|
|
End
对应项目:ProjectPatternStudy 😁
此文仅个人总结,如有不当之处,请留言告知。