Android三种常见软件架构MVC MVP MVVM

简析MVC MVP MVVM及区别

 

1、MVC:

MVC，Model+View+Controller作为一种最为常规常见的设计模式，在Android开发历程初期被频繁使用。

 

设计原理：

  一个指令的下发和执行过程为,用户通过View发送指令给Controller,Controller去通知Model更新数据，Model层更新完数据直接响应到View层

 

 

Android中使用场景：

   在MVC架构中，布局文件、xml作为MVC中的View层用于展示数据信息；Model指的是我们定义的JavaBean、UseCase、Repository等处理数据的相关对象，例如取数据库，网络请求；Controller则是Activity,例如点击“登录”按钮进行系统登录操作时，activity中定义onClick事件，通过HTTP请求网络判断用户信息准确性后进行Toast提示和页面跳转。

 

 

 

分析：

  使用MVC架构，我们可以较为简单，快速地实现我们想要的功能。然后在Android当中，由于xml中布局文件只能通过activity绑定的方式，因此相应实现View层控制也必须在Activity中操作，所以我们的activity既作为View层，同时又是Controller,也就是大量的逻辑处理需要在activity中完成，从而使得activity中的逻辑复杂而难于维护。同时也可以看到，在这种设计中View层与Model或者说所谓的Data层互知，两者之前耦合度较高，不利于后期的扩展和维护。

 

 

2、MVP

MVP,Model+View+Presenter模式，是现在项目开发中较为常见的一种设计模式。

设计原理：

   用户指令通过View下发，View层调用绑定的Presenter通知Model层做出相应的数据操作，完成后再由Presenter通过接口形式在View中显示

 

 

 

Android中使用场景：

  在MVP架构中，与MVC相同的是布局文件、xml作为MVC中的View层用于展示数据信息,而此时通常将相关的界面操作都抽象为接口形式，例如LoginActivity抽象为LoginView，供后续的Presenter调用；Model指的是我们定义的JavaBean、UseCase、等处理数据的相关对象，例如取数据库，网络请求,；Presenter则是作为发送用户指令和直接更新界面的中间件。

     用户发送指令通过Presenter控制Model或UseCase去处理数据，数据更新后再由Presenter操作绑定的View接口使得继承该View的Activity、Fragment或者控件显示数据变化。例如点击“登录”按钮进行系统登录操作时，activity中定义onClick事件，调用Presenter.login()方法，Presenter调用UserLoginUseCase去请求网络判断用户信息准确性后再通知Presenter调用LoginView.loginResult()使继承LoginView进行Toast提示和页面跳转。

 

 

 

分析：

  使用MVP架构，我们实现View层与数据层解耦，使用中间件去同步二者，提高层级的单一职能性与降低代码耦合，另外还有一个好处就是由于Model独立于View,我们可以推翻View层与Presenter层而不对Model有影响，使得我们在版本更新后维护过程中能够最大程度复用底层的逻辑结构。但是此模式依赖抽象接口，因此在开发过程中简单的逻辑仍然需要定义相应的接口去实现，并且当同类View层使用同一接口时可能部分activity就需要继承无谓的接口。

 

3、MVVM

MVVM,Model+View+ViewModel。

设计原理：

  与MVP类似，用户指令通过View下发，View层通过Data Binging绑定的ViewModel通知,ViewModel操作Model进行完数据操作后，响应到ViewModel层,由于ViewModel与View绑定，VM中的数据更新之后会同步到View中