Android中常用的两种框架设计模式 MVC和MVP，MVVM

最新推荐文章于 2021-05-25 17:54:42 发布

jsx9057

最新推荐文章于 2021-05-25 17:54:42 发布

阅读量1k

点赞数 1

分类专栏：技术点

本文链接：https://blog.csdn.net/jsx9057/article/details/51896512

版权

技术点专栏收录该内容

10 篇文章 0 订阅

订阅专栏

什么是MVC

    Android中常用的两种框架设计模式 MVC和MVP。
MVC全名是Model View Controller，
    是模型(model)－视图(view)－控制器(controller)的缩写，
一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，
    将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，
来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。

mvc是model,view,controller的缩写，从上图可以看出mvc包含三个部分：

　　l模型（model）对象：是应用程序的主体部分，所有的业务逻辑都应该写在该层。

　　l视图（view）对象：是应用程序中负责生成用户界面的部分。也是在整个mvc架构中用户唯一可以看到的一层，接收用户的输入，显示处理结果。

　　l控制器（control）对象：是根据用户的输入，控制用户界面数据显示及更新model对象状态的部分，控制器更重要的一种导航功能，想用用户出发的相关事件，交给m哦得了处理。

　　android鼓励弱耦合和组件的重用，在android中mvc的具体体现如下：

　　1)视图层（view）：一般采用xml文件进行界面的描述，使用的时候可以非常方便的引入，当然，如何你对android了解的比较的多了话，就一定可以想到在android中也可以使用javascript+html等的方式作为view层，当然这里需要进行java和javascript之间的通信，幸运的是，android提供了它们之间非常方便的通信实现。

　　2)控制层（controller）：android的控制层的重任通常落在了众多的acitvity的肩上，这句话也就暗含了不要在acitivity中写代码，要通过activity交割model业务逻辑层处理，这样做的另外一个原因是android中的acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

　　3)模型层（model）：对数据库的操作、对网络等的操作都应该在model里面处理，当然对业务计算等操作也是必须放在的该层的。

什么是MVP

　　MVP是模型（Model）、视图（View）、主持人（Presenter）的缩写，分别代表项目中3个不同的模块。

　　模型（Model）：负责处理数据的加载或者存储，比如从网络或本地数据库获取数据等；

　　视图（View）：负责界面数据的展示，与用户进行交互；

　　主持人（Presenter）：相当于协调者，是模型与视图之间的桥梁，将模型与视图分离开来。

　　如下图所示，View与Model并不直接交互，而是使用Presenter作为View与Model之间的桥梁。其中Presenter中同时持有Viwe层以及Model层的Interface的引用，而View层持有Presenter层Interface的引用。当View层某个界面需要展示某些数据的时候，首先会调用Presenter层的某个接口，然后Presenter层会调用Model层请求数据，当Model层数据加载成功之后会调用Presenter层的回调方法通知Presenter层数据加载完毕，最后Presenter层再调用View层的接口将加载后的数据展示给用户。这就是MVP模式的整个核心过程。

　　这样分层的好处就是大大减少了Model与View层之间的耦合度。一方面可以使得View层和Model层单独开发与测试，互不依赖。另一方面Model层可以封装复用，可以极大的减少代码量。

什么是MVVM

MVVM模式包含了三个部分：

Model – 代表你的基本业务逻辑
View – 显示内容
ViewModel – 将前面两者联系在一起的对象

一个ViewModel接口提供了两个东西：动作和数据。动作改变Model的下层（click listener，监听文字改变的listener等等），而数据则是Model的内容。

比如，为一个拍卖页面服务的ViewModel可能被作为数据呈现：item里的一张图片，标题，描述，价格。也可能作为动作呈现：投标，购买或者联系卖家。

在传统的安卓架构中，controller负责推送数据给view。在Activity中findview，然后在它上面设置内容。在MVVM中，ViewModel在改变内容之后通知binding framework内容发生了改变。然后framework自动更新和那些内容绑定的view。这两个组建只是通过ViewModel松耦合在一起。

这种设计模式之所以牛逼，除了明显智能化了的View之外，还方便了测试。

因为ViewModel不在依赖于View了，你可以在没有View的情况下也能测试ViewModel。在合适的依赖注入的帮助下，测试就会变得非常简单。

比如，在一个测试用例中，我们不将VM和一个真实的View绑定，而是直接创建一个VM，给它一些数据，然后在上面调用操作，以确保数据的变化是正确的。比如刚刚的拍卖案例中，你可以创建一个带虚拟（模拟的）API服务的VM

，让它载入任意的item然后在上面调用拍卖的行为，以确认结果数据是正确的。所有这些工作都不必和一个具体的View交互。

而在测试view的时候，我们可以创建一系列带有预先设置好数据（比如依赖于网络调用的或者数据库内容的）的模拟model，然后观察在不同的数据集合面前view是如何表现的