Android框架中的MVC、MVP、MVVM设计思想
框架和设计模式的异同
框架并非设计模式,框架中包含有设计模式,对框架而言是对相同行为代码的重用,而设计模式是对相同结构代码的重用。框架适用于系统模块开发,而设计模式适用于功能模块开发。框架是大智慧,对系统软件设计进行分工,明确各自职能; 设计模式是小技巧,对具体问题提出应对策略,提高代码复用率,降低系统耦合。
框架的适用性
并不是开发一个系统就需要使用框架,框架所做的事是把模块分离开发,让专业人员做专业的事,比如MVC框架,视图层由前端人员开发,后端工程师则专注业务逻辑开发。但这毫无疑问分离开来会增加文件数量,而且调试也需要进一步沟通,如果手上的是一个小项目,仅仅百行代码如果用了MVC那会适得其反,但如果是商业化的大项目,使用框架就如鱼得水。
图示
由3者的图示我们总结下:
- MVC:View直接访问Model,3者构成回路,耦合度大
- MVP:View与Model解耦,通过中介者Presenter简介请求访问
- MVVM:与MVP很相似,View与Model 的双向绑定,不需要中介者,View一经改变立刻通知到Model
MVC
经典的设计框架,而且Android中也已经预先为我们实现好了的:
- Model–本地实体数据文件、或其他数据体
- View–XML文件(layout显示相关部分)
- Controller–Activity组件
具体实现就不多叙述了,日常开发中我们遵循的基础就是系统搭建好的这个MVC框架,我们基本不会刻意去修改实现。
优点:经典的框架,业务逻辑集中在Controller,当需要逻辑变更不需要动Model和View只需要替换Controller即可。
缺点:测试困难,View依赖Model存在,耦合度大,不易剥离
MVP
MVP可以是称为是MVC的升级版,MVC的模式虽然很经典,但进步总是建立在修改的基础上的。MVC的不足之处是无经验的开发人员会将Model与View混为一谈,业务逻辑和数据存取出现在同一Activity中并不是空穴来风,引发类型膨胀的问题。如果产品升级需要重新开发UI,这时候就牵扯到数据逻辑的开发人员。
所以MVP就是升级来解决这个问题的。
- Model–数据的存取
- View–用户界面(xml文件显示相关)
- Presenter–中介者(View和Model沟通的桥梁)
优点:解耦View与Model的联系,便于测试,Controller不依赖View环境测试,View针对接口存在,易于剥离
缺点:Presenter中存在大量View、Model同步的问题
MVVM
- Model–数据存取
- View–用户界面
- ViewModel–View、Model视图绑定机制
MVVM与MVP的区别是,让View和Model双向绑定,实现类似于观察者模式,View改变则通知Model相应改变,相反Model改变也通知View改变。
优点:解决View–Model手动同步问题,简化测试操作,减小同步更新以及后续操作
缺点:非复杂项目不建议采用,不适用于视图少的项目,维护成本较高
总结
MVC–>MVP–>MVVM,逐步升级,后者改善前者的不足,把缺点变成优点,但并不是说MVVM就是最终最好的,解决上一代不足的问题后肯定会有其他负面影响的,实际开发中要根据实质情况,选择需要用哪一个。