Android 中MVC、MVP以及MVVM架构介绍

        MVC、MVP和MVVM是目前Android架构中常见的三种架构设计模式，接下来详细介绍下这三种架构的特点以及差异。

 一、MVC

    1.定义：

     MVC (Model-View-Controller, 模型-视图-控制器)，标准的MVC是这个样子的：

• 模型层 (Model)：业务逻辑的处理，数据的实体类和存取等；
• 视图层 (View)：一般使用XML或者Java对界面进行描述；
• 控制层 (Controller)：在Android中通常指Activity和Fragment，或者由其控制的业务类。

        在Android中，可以说默认就使用了MVC来进行开发，Model好比我们的方法类，一些具体功能的实现类；而View就类似于我们对应的布局，例如那些xml文件；而Controller就是Activity或者Fragment，它持有View，即控件们的对象，及一些Model，即方法类的对象，并且让他们进行交互，相当于是他们之间的桥梁。
    2.交互图：

    3.特点：
    优点：Model，View，Controller各司其职，区分明确且易于理解。

    缺点：由于xml能实现的功能有限，很多View层应该做的事情被迫让Activity，也就是Controller层来做，并且很多业务逻辑也是融合在Activity里，这就导致Controller层逻辑复杂了起来，导致他们之间的分工不再那么明确，最终导致了Activity类过于臃肿，并且View可以直接和Model交互，这让原本应该是Controler层负责的工作又模糊了起来。

     4.使用场景：

     适用于较小，功能较少，业务逻辑较少的项目。

二、MVP

     1.定义：

       MVP (Model-View-Presenter) 是MVC的演化版本，几个主要部分如下：

• 模型层 (Model)：主要提供数据存取功能。
• 视图层 (View)：处理用户事件和视图。在Android中，可能是指Activity、Fragment或者View。
• 协调层 (Presenter)：负责通过Model存取数据，连接View和Model，从Model中取出数据交给View。

     2.交互图：

   3.特点
    优点：

    （1）模型与视图完全分离，可以修改视图而不影响模型。

    （2）可以更高效地使用模型，因为所有的交互都发生在 一个地方——Presenter内部。

     （3）可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。

    （4）如果把逻辑放在Presenter中，那么就可以脱离用 户接口来测试这些逻辑（单元测试）。

    缺点：

      由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。由于View到Model和Model到View都需要Presenter来实现，这使得Presenter也过于笨重，且由于Presenter双向都需要接口来隔离和调用，大量的接口也使得维护的复杂度上升。

      4.使用场景：

       视图界面不是很多的项目中。

三、MVVM

        1.定义：

          MVVM 是 Model-View-ViewModel 的简写。它本质上就是 MVC 的改进版。MVVM 就是将其中的 View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。

• 模型层 (Model)：负责从各种数据源中获取数据；
• 视图层 (View)：在 Android 中对应于 Activity 和 Fragment，用于展示给用户和处理用户交互，会驱动 ViewModel 从 Model 中获取数据；
• ViewModel 层：用于将 Model 和 View 进行关联，我们可以在 View 中通过 ViewModel 从 Model 中获取数据；当获取到了数据之后，会通过自动绑定，比如 DataBinding，来将结果自动刷新到界面上。

      2.交互图：

    3.特点:
    优点：跟MVP中的P相比，VM显得轻量化一些，由于有databind的存在，不需要去自己同步View和Model，所以MVVM相比MVP的类的数量也会少一些。

    缺点：由于元素定义在xml中，View关于绑定的这部分内容是没办法打断点进行测试的，且对于小的界面，代码量过于庞大，对于复杂的界面，ViewModel又有些难以构建和维护。
     4.使用场景：

      适用于界面展示的数据较多的项目。

      任何的项目框架，都是为项目服务的。没有绝对的好坏之分，只有更合适的选择。在项目进展的不同阶段，做出最合适的调整，才是是更适合团队项目发展的框架。    

     任何的项目设计，都是要围绕项目发展阶段，团队成员规模，和团队整体能力而定的。切莫为了设计而设计，为了框架而框架。快速，高效的配合整个团队进展项目，才是最合适的架构。