image.png
mvp 相对于mvc 主要是将m与v进行拆分；
在mvc中 Activity 既要去处理 c 的工作，还得去更新v ；在mvp中 由p去控制，activity去做v处理显示
在mvc中，mv的分层总给人傻傻分不清的感觉，而且布局xml的作用过于弱，Activity即要去做控制，也要去处理view的交互，过于耦合。
为了解决这个问题，便诞生了mvp的设计模式，主要目的就是将Activity这个既要做controler也要做view的交互的模块进行解耦，把控制层交给presenter去处理，而Activity只做view层的处理，model层还是做数据的交互，但是与view层毫无联系，这便是mvp。
但是mvp有个缺点就是随着业务的不断扩充，一个页面可能非常复杂，UI的改变是非常多的，便会有非常多的case，这样就会造成View的接口会非常的庞大；
为了解决这个问题，MVVM就出现在了历史的舞台上，通过双向绑定的机制，实现数据和UI内容，只要想改变其中的一方，另一方可以及时的更新的设计理念，这样省去了在View层写很多case的情况，只需要改变数据即可。
MVVM的缺点：但是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel、LiveData、DataBinding去实现MVVM
如何选择？
1、如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
2、对于偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。
3、对于工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可。
4、如果想通过一个项目去学习架构和设计模式，建议用MVC然后在此基础上慢慢挖掘改进。最后你可能发现，改进的最终结果可能就变成了mvp，mvvm。
网友评论