上个月参加了敏捷之旅成都站的活动, 其中有一个朋友分享了 "提升软件研发领导力的招式和模式", 模式用通俗一点的说法就是 "套路", 他介绍了模式 (套路) 在我们生活和工作中的积极作用,"模式并不是一项新发明, 而是一个被记录和证实的最佳实践或者一个解决方案, 而且在特定环境下, 模式是可以复制的", 包括我们常听到的设计模式其实也是这样.
一个人善于使用模式, 相当于把一些特定问题进行了抽象概括, 大脑其实可以腾出更大的空间处理别的事情(具体的业务等). 所以, 这一两年我也比较喜欢尝试使用一些流行的模式或者开源框架到自己的项目中, 最终不一定会投入使用, 但尝试的过程还是很有益处的.
今天就来和大家谈一谈最近一两年在 Android 开发中比较火的模式: MVP & MVVM.
面试题: 谈谈 MVP 和 MVVM 模式, 你有在自己的项目中使用过吗?
好吧, 其实问过很多面试者, 结果说明 MVP 和 MVVM 模式并没有到妇孺皆知的境地. 不过也好, 这么一个简单的问题我们就可以很容易区分出面试者是否对 Android 开发有热情.
在解释 MVP 时, 我们往往喜欢拿它和大众都比较熟悉的 MVC 进行比较.
MVC 全名是 Model--View--Controller, 是模型 (model)- 视图(view)- 控制器(controller) 的缩写, 一种软件设计典范, 用一种业务逻辑, 数据, 界面显示分离的方法组织代码, 在改进和个性化定制界面及用户交互的同时, 不需要重新编写业务逻辑. 其中 Model 层处理数据, 业务逻辑等; View 层处理界面的显示结果; Controller 层起到桥梁的作用, 来控制 View 层和 Model 层通信以此来达到分离视图显示和业务逻辑层.
我们往往把 Android 中界面部分的实现也理解为采用了 MVC 框架, 常常把 Activity 理解为 MVC 模式中的 Controller.
而 MVP 其实是 MVC 的一种演进版本, 它更简单, 将 MVC 中的 Controller 改为了 Presenter,View 通过接口与 Presenter 进行交互, 降低耦合, 方便进行单元测试.
View: 负责绘制 UI 元素, 与用户进行交互(Activity,View,Fragment 都可以做为 View 层);
Model: 对数据的操作, 对网络等的操作, 和业务相关的逻辑处理;
Presenter: 作为 View 与 Model 交互的中间纽带, 处理与用户交互的逻辑. 可以把 Presenter 理解为一个中间层的角色, 它接受 Model 层的数据, 并且处理之后传递给 View 层, 还需要处理 View 层的用户交互等操作.
我们看看如下的 MVC 和 MVP 的对比图更能直观的理解这两种模式的区别:
最明显的区别就是, MVC 中是允许 Model 和 View 进行交互的, 而 MVP 中很明显, Model 与 View 之间的交互由 Presenter 完成.
那么我们为什么需要 MVP 或者其他模式呢? 现实中, 我们常遇到一些不使用架构的项目(程序员都很任性, 功能需求到哪里代码就写到哪里), 需求中的一个页面对应项目中的一个 activity 或一个 fragment, 所有的界面响应代码, 业务逻辑代码, 数据请求代码等等都集中在其中, 一个类的代码非常臃肿难于理解和维护.
如何在自己的项目中使用 MVP
官方给我们写了一些 MVP 的样例工程, 用不同的概念和工具实现同一个 Todo 项目.
GitHub 地址
- mvp 基础架构示例.
- 基于 mvp 基础架构项目, 获取数据部分使用了 Loaders 架构.
- 基于 mvp 基础架构项目, 使用了数据绑定组件.
- 基于 mvp 基础架构项目, 使用了 clean 架构的概念.
- 基于 mvp 基础架构项目, 使用了 dagger2 进行依赖注入.
- 基于 todo-mvp-loaders 架构项目, 使用了 Content Providers
- 基于 mvp 基础架构项目, 全名用 RxJava 进行并发和数据层处理.
虽然在官方推出这套 MVP 开源用例之前, 网络上也有很多优秀的开源项目教大家如何使用 MVP 模式, 如果你之前没看过, 其实现在还有一个好处, 直接按官方的来做就是了(官方一出马, 其他的类似项目就哑火了). 我看了一下官方的 todo-mvp 确实比之前自己实现的要简单明了一些, 而且测试用例也写得比较完整可以直观体验一下 MVP 在这方面的好处.
MVP 的好处与问题
当你了解清楚 MVP 模式后, 它的好处也就很明显了:
UI 层和逻辑层分离, UI 层不在涉及业务逻辑代码, 某层的改动不需要到处去修改代码;
测试很方便, 你可以直接调用 Presenter 层写测试用式(可以使用 Junit 框架);
最后是可维护性和可扩展性, MVP 的各个类职责都非常明确且单一, 后期的扩展, 维护都会更加容易.
当然, 坏处也很明显, 首先代码类增加了, 一个小功能你可能要为它专门写 Presenter 和 Model 层的实现, 以前这些你一口气就加在 View 层了. 同时需要对新进项目的人员进行一些 MVP 模式的培训, 以便他们不会写出破坏已有模式的代码.
MVVM 模式
MVVM 模式(Model--View--ViewModel 模式), 和 MVP 模式相比, MVVM 模式用 ViewModel 替换了 Presenter , 其他层基本上与 MVP 模式一致, ViewModel 可以理解成是 View 的数据模型和 Presenter 的合体.
MVVM 采用双向绑定(data-binding):View 的变动, 自动反映在 ViewModel, 反之亦然, 这种模式实际上是框架替应用开发者做了一些工作(相当于 ViewModel 类是由库帮我们生成的), 开发者只需要较少的代码就能实现比较复杂的交互. 这一步对于我还是比较有吸引力了, 可以少写很多模板代码.
官方在 Google I/O 2015 大会上推出来 MVVM 模式的支持函数库 Data Binding Library. 在 Android Studio 2.1 Preview 3 之后, 开始支持双向数据绑定, 即在 View 层修改输入也会触发 Model 层的改变.
当然, 做过 WinPhone 开发的人一定想起来了微软在很多年前就在使用 MVVM 模式了.
小结
再次说明, 你的项目并不一定非要用 MVP/MVVM 或者别的什么模式, 模式都有它们自身应用的场景, 有好处也就会有坏处. 但了解是必需的, 不然你很难扩展自己的技能范围, 高级的开发应该学会判断某个项目是否合适一些现成的模式, 合理的使用模式会让你的应用框架更加清晰并且易于维护和扩展.
最后
在这里我总结出了互联网公司 Android 程序员面试简历模板, 面试涉及到的绝大部分面试题及答案做成了文档和架构视频资料免费分享给大家[包括高级 UI, 性能优化, 架构师课程, NDK,Kotlin, 混合式开发(ReactNative+Weex),Flutter 等架构技术资料] , 希望能帮助到您面试前的复习且找到一个好的工作, 也节省大家在网上搜索资料的时间来学习.
来源: http://www.jianshu.com/p/9043f850604f