Android 设计模式MVC、MVP、MVVM
Android 设计模式MVC、MVP、MVVM
MVC:
概念：
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。
缺点：
在Android中的activity并不是标准的mvc架构中的controller，他的职责是加载应用布局,初始化后应用view。并处理来自用户的操作做出响应。然而随着界面和逻辑的越来越复杂，activity需要处理的事物越来越繁杂，最终导致activity变得臃肿。
设计模型：
在Android中，view表示视图层，controller表示控制层，model模型层。
- 视图层(view)
一般用XML文件进行界面描述，使用时方便引入，同时方便后期修改，增强代码的可维护性。 - 控制层(controller)
Android中的controller一般是activity，在activity中控制view与逻辑的通信。 - 模型层(model)
模型层处理的就是程序中的业务逻辑，数据结构和相关的类，比如数据库的操作、网络操作、数据处理等。model与view无关，与业务相关，model与view的联系在于controller这个桥梁。
应用：
在一个页面中，activity有个button，当用户点击button时，activity作为controller控制层读取了view视图层的textview数据，然后想model模型发送数据处理请求，model模型处理完成后调用接口通知view视图处理结果，view视图层更新UI界面。如此activity就将view视图的显示和model模型数据处理分割开了，activity作为controller完成了view和model的之间协调作用。
优点与缺点
优点
- 耦合性低
- 重用性高
- 可维护性高
缺点
- 增加系统结构和实现的复杂性
- view和Control联系过于紧密
- view对model的访问效率过低
MVP:
概念：
MVP全名是 Model View Presenter，是模型(model)、视图(view)、控制(presenter)的缩写，是一种软件设计规范，它从MVC演变过来，和MVC具有一定的相似性。它的出现是为了解决MVC中controller存在的问题，在一些视图效果或事物逻辑复杂的情况，activity需要处理大量事物，导致activity越来越任务繁重，最终变得越来越臃肿。
设计模型：
MVP框架由3部分组成，期中model表示模型层，提供数据；view表示视图层负责数据的显示；presenter表示控制层负责逻辑处理；如果加上view interface就是4个。
- view interface 是view需要实现的接口，view通过view interface与presenter进行交互，降低耦合。
- 使用场景在Android开发中进行单元测试需要部署到真机或模拟器上，而往往这样会耗费大量时间（编译、安装），导致开发效率降低。而在MVP模式当中，复杂的逻辑是presenter通过interface与view进行交互的，那么我们可以自己写一个类去模拟交互，进行单元测试，这样可以节省开发时间提高效率。
应用：
在实际开发中，一般可以将程序结构进行划分为3层，模型层、UI层、逻辑层。UI层包括activity、fragment、adapter等，UI层在activity启动后初始化presenter，然后由presenter进行程序控制。
在一个页面中有一个button，当用户点击button后，UI层通知逻辑层，逻辑层决定应该如何响应，然后通过model处理数据，将结果通知到UI层进行更新。
优点与缺点
优点
- 只需定义好view和Presenter，即可实现UI与业务逻辑层的开发，可由不同团队分别实现
- 业务逻辑只在Presenter中维护，遵循了单一职责设计原则，提升了代码的可维护性
- 低耦合
- 模块职责划分明显
缺点
- view和Presenter交互过于频繁，如果需要频繁更新某个view，那么该Presenter与那个view联系会过于紧密
MVP与MVC：
MVP的presenter是框架的控制者，承担了大量的逻辑操作，而MVC的controller更多时候是承担view与model的交流，作为一个中间人的存在。 因此在APP中引入MVP的原因是，为了将此前activity中大量的逻辑操作放到控制层，避免activity的臃肿。
两者区别：
- MVC：view可以与model直接交互。MVP：view不可直接与model直接交互，而是通过presenter间接交互。
- MVC：controller控制view显示，并且一个controller可以有多个view。
- MVP：通常view与presenter是一对一的，但是复杂的view会有多个presenter来处理逻辑。
- MVP：presenter与view的交互是通过接口进行，利于进行单元测试。
MVVM：
概念：
mvvm全称是model view ViewModel，它是 MVP 的升级版。其中ViewModel是Jetpack中的一个组件，在这个设计模式中ViewModel 代替了presenter，MVP中presenter是通过interface与view进行交互，而mvvm中viewModel通过data binding完成这一操作，data binding可以实现双向交互，这样使得视图与控制层耦合进一步降低。
优点与缺点
优点
- 双向绑定，当model中数据更新了，view也会变化
- view和控制层的耦合进一步降低
缺点
- dataBinding的双向交互使得bug排查很麻烦，调试困难
- dataBinding不利于代码重用
- 大的模块，model很大，会占用更多内存
MVC、MVP、MVVM 三种设计模式总结
MVC->MVP->MVVM三种设计模式是一步一步演化发展的，从MVC中因为controller的不足演化到MVP，MVP隔离了MVC中的model与view的直接联系，通过presenter进行中转交互。这时MVP设计模式因为presenter通过interface与view进行交互，已经方便测试。但是代码不够简洁。于是从MVP设计模式演变到了MVVM设计模式，MVVM出现了vm(viewModel)这一概念，它代替了presenter，viewModel通过data Binding与view进行交互。
在三种设计模式中：
相同点
- model： 始终作为数据对象，提供数据处理操作。
- view： UI层，UI实现和用户交互操作。
不同点 （三者的差异在于不同处理view与model的交互）
- controller
controller接收view的操作请求，根据事件选择model进行数据处理，然后model通知view进行UI更新。通常一个controller对应多个view和多个model。 - presenter
presenter与controller一样接收view的操作请求，然后对model进行数据操作，但是不同的是，view不能与model进行直接交互，model完成数据处理后不能直接通知view，而是通知presenter，然后presenter进行通知view更新。在这个模式下，activity控制view的变化，而不是controller。一个view对应一个presenter。 - viewModel
viewModel中的model和MVVM中的model不是一回事，它指view的model，也就是view的数据属性和操作等等。这个模式的关键在于数据绑定(data binding),view的变化直接影响viewModel，viewModel的变化也会在view上体现。
在实际开发过程由于情况复杂，我们往往不会仅使用一种开发模式，因为需要根据需求情况随机应变。比如在MVP模式或MVVM模式中，数据拷贝开销很大时，我们可能会结合mvc模式，model直接通知view进行处理，往往最后是多种模式融合在一起，但不管如何，我们都要保证代码的可扩展、可测试、可阅读还有模块间的解耦。
