安卓如何搭建Mvvm框架

安卓架构从我们最初熟悉的Mvc模式，发展到用Mvp，再到现在比较火的Mvvm架构。一路走来感觉架构都是浮云，最主要的还是个人对业务的理解深入，然后再进行代码的封装解耦，才能真正是代码逻辑简洁和维护成本减小。
下面我们就来对比一下这三种模式的区别和各自的特点。
MVC框架

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

结构图一：
在这里插入图片描述

通过模型图我们可以知道Mvc模式只是按功能把代码分为了View、Model 、Controller三种职能类型代码。View主要就是展示给用户可以看到的界面，比如Activity、Dialog、Popwindow、系统控件、还有就是一些自定义控件；然后model职能类就是对数据体的一些封装类，比如Person类，里面有name、age等属性：

class Person{
private String name;
private int age;
}

然后Model类一般都会提供set和get属性值的方法提供给外界使用。最复杂的要说是Controller职能类了，因为它不仅仅只是提供了界面View和用户直接的交互，而且还需要通过访问网络接口实现数据的更新和保存，这里也就是为什么Controller职能类需要和View层和Model层建立联系的原因。
Controller层首先通过访问网络获取数据，然后更新Model层的数据，再显示在View层展示给用户，然后根据用户的手势操作，再进行界面的展示和数据的更新。这里我们可以方向Mvc模式或者说是架构，完全符合我们的业务场景，这也是Mvc使用最普遍和最长久的原因之一。

   这里我们总结一些Mvc的优缺点:优点：耦合性低、重用性高、生命周期成本低、部署快、可维护性高、有利于软件工程管理。缺点：没用明确的定义、视图对模型数据的低效率访问、增加系统结构和实现的复杂性、不适合小、中型应用程序。

接下来我们来看看Mvp架构模型：在Android项目中，Activity和Fragment占据了大部分的开发工作。如果有一种设计模式（或者说代码结构）专门是为优化Activity和Fragment的代码而产生的，你说这种模式重要不？这就是MVP设计模式。
MVP模式简称：MVP 全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。 在这里插入图片描述
作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的改变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
虽然 MVC 中的 View 的确“可以”访问 Model，但是我们不建议在 View 中依赖 Model，而是要求尽可能把所有业务逻辑都放在 Controller 中处理，而 View 只和 Controller 交互。

作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的改变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
虽然 MVC 中的 View 的确“可以”访问 Model，但是我们不建议在 View 中依赖 Model，而是要求尽可能把所有业务逻辑都放在 Controller 中处理，而 View 只和 Controller 交互。

优点：
1、模型与视图完全分离，我们可以修改视图而不影响模型
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
缺点：
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。

下面我们再来学习一些Mvvm架构：
简单了解Mvvm架构模式:
开源框架，MvvmHabit

框架和设计模式的区别
有很多程序员往往把框架模式和设计模式混淆，认为MVC是一种设计模式。实际上它们完全是不同的概念。
框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。框架通常是代码重用，而设计模式是设计重用，架构则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。
框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。
框架模式有哪些？
MVC、MTV、MVP、CBD、ORM等等；
框架有哪些？
C++语言的QT、MFC、gtk，Java语言的SSH 、SSI，php语言的 smarty(MVC模式)，python语言的django(MTV模式)等等
设计模式有哪些？
工厂模式、适配器模式、策略模式等等
简而言之：框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。