三大架构的比较

逃离我推掉我的手 2022-06-07 14:16 137阅读 0赞

**关于作者**

作者：liujc

博客地址：http://www.jianshu.com/u/0633b9f8256b

声明：本文由作者授权发布，未经原作者允许请勿转载

**MVC**

模型层(Model)  
负责存储、检索、操纵来自数据库或者网络的数据

视图层(View)  
用户界面，一般采用XML文件进行界面的描述

控制层(Controller)  
业务逻辑处理

![640_wx_fmt_png_wxfrom_5_wx_lazy_1][]

1. 工作原理

*  当用户出发事件的时候，view层会发送指令到controller层，自己不执行业务逻辑。
 *  Controller执行业务逻辑并且操作Model，但不会直接操作View，可以说它是对View无知的。
 *  model层更新完数据然后对视图进行更新，用户得到反馈。

### 2. MVC代码实例 ###

*  1.先实现一个 model，需要有通知View更新的能力,当model加载成功，模拟从网络或者本地获取数据，需要告知View更新：

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 1]

*  2.View  
    View需要发出点击事件，并且传递Controller,同时需要根据Model更新UI：

![从图库选择图片][Image 1]

1.  Controller ：有时候我们的Activity既充当View也充当Controller， 这里为了更好的理解MVC，将Activity进行了拆解。

![从图库选择图片][Image 1]

### 3. MVC调用链 ###

1.  View:OnClick ->
2.  Controller:loadData->
3.  Model:loadModel->
4.  View:updateUI

### 4. MVC优缺点 ###

*  优点：  
    把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了。
 *  缺点：  
    1、 Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。  
    2、 xml作为view层，控制能力实在太弱，Activity基本上都是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能很多，导致代码量很大。如想去动态的改变一个页面的背景，或者动态的隐藏/显示一个按钮，这些都没办法在xml中做，只能把代码写在activity中，造成了activity既是controller层。  
    3、 view层和model层之间存在耦合。

**MVP**

*  模型层(Model)  
    负责存储、检索、操纵来自数据库或者网络的数据。
 *  视图层(View)  
    用户界面，一般采用XML文件进行界面的描述。
 *  逻辑处理层（Presenter）  
    作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。

![640_wx_fmt_png_wxfrom_5_wx_lazy_1 2][]

### 1. 工作原理 ###

1.  View 接受用户请求
2.  View 传递请求给Presenter
3.  Presenter做逻辑处理，修改Model
4.  Model 通知Presenter数据变化
5.  Presenter 更新View

### 2. MVP代码实例 ###

MVP中Model、View、Presenter中的联系件

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 3]

还在MVC的例子上变动，需要先对Model进行封装，当loadModel后，不直接通知View更新，而是通知Presenter。

![从图库选择图片][Image 1]

View需要发出点击事件，并且传递给Presenter ，最后也由Presenter去通知View更新UI：

![从图库选择图片][Image 1]

Presenter ，接收到来自View的操作命令后，进行逻辑处理，处理Model，修改完成后 通知View进行修改。

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 4]

### 3. MVP调用链 ###

1.  View:OnClick ->
2.  Presenter:loadData->
3.  Model:loadModel->
4.  Presenter:onSuccess->
5.  View:updateUI

### 4. MVP优缺点 ###

*  优点：  
    1、便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
    
    2、避免了传统开发模式中View和Model耦合的情况，提高了代码可扩展性、组件复用能力、团队协作的效率。
 *  缺点：  
    1、 View(Activity)需要持有Presenter的引用，同时，Presenter也需要持有View(Activity)的引用，增加了控制的复杂度；
    
    2、MVC中Activity的代码很臃肿，转移到MVP的Presenter中，同样造成了Presenter在业务逻辑复杂时的代码臃肿。

**MVVM**

*  模型层(Model)  
    负责存储、检索、操纵来自数据库或者网络的数据
 *  视图层(View)  
    用户界面，一般采用XML文件进行界面的描述
 *  视图-模型层(ViewModel)  
    负责View和Model之间的通信，以此分离视图和数据。![640_wx_fmt_png_wxfrom_5_wx_lazy_1 5][]

### 1. 工作原理 ###

1.  View 接收用户交互请求
2.  View 将请求转交给ViewModel
3.  ViewModel 操作Model数据更新
4.  Model 更新完数据，通知ViewModel数据发生变化
5.  ViewModel 更新View数据

### 2. MVVM代码实例 ###

1.Model

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 6]

2.ViewModel

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 7]

3.接着使用databinding语法 对 xml 进行数据绑定,我们将 Click事件、输出结果都绑定到ViewModel上。

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 8]4.最后在View(Activity)中引入ViewModel ：

![从图库选择图片][640_wx_fmt_png_wxfrom_5_wx_lazy_1 9]

### 3.MVVM优缺点 ###

*  优点：  
    1、低耦合。View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
 *  2、可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
 *  3、独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，生成xml代码。
 *  4、ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题，界面由数据进行驱动，响应界面操作无需由View(Activity)传递，数据的变化也无需Presenter调用View(Activity)实现，使得数据传递的过程更加简洁，高效。
 *  缺点：  
    
    
    1、ViewModel中存在对Model的依赖。  
    2、数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。  
    3、IDE不够完善（修改ViewModel的名称对应的xml文件中不会自动修改等）。

**Databing**

DataBinding是2015年谷歌 I/O大会上介绍了一个数据绑定框架，以前我们可能需要在每个Activity里写很多的findViewById，不仅麻烦，还增加了代码的耦合性，如果我们使用DataBinding，就可以抛弃那么多的findViewById，省时省力。

双向绑定的概念让传统的布局文件由被动转为主动，数据驱动UI，而且View与ViewModel实现了完美的解耦，这也解决了MVP模式下的缺点。

**总结**

从MVC、MVP到MVVM，实际上是模型和视图的分离过程。MVC中模型和视图没有完全分离，造成Activity代码臃肿，MVP中通过Presenter来进行中转，模型和视图彻底分离，但由于V和P互相引用，代码不够优雅。ViewModel通过Data Binding实现了视图和数据的绑定，解决了这种MVP的缺陷。

可参考一套Android App基础框架

架构设计：从MVC、MVP到MVVM  
网络访问：支持REST、HTTPS及SPDY的Retrofit+Okhttp  
响应式编程：RxJava/RxAndroid解决方案  
依赖注入：Dagger2和ButterKnife使用

框架的选择  
任何的项目框架，都是为项目服务的。没有绝对的好坏之分，只有更合适的选择。在项目进展的不同阶段，做出最合适的调整，才是是更适合团队项目发展的框架。谨记任何的项目设计，都是要围绕项目发展阶段，团队成员规模，和团队整体能力而定的。切莫为了设计而设计，为了框架而框架。快速，高效的配合整个团队进展项目，才是最合适的架构。

**推荐阅读**

[他们说学历不重要，可怜你深信不疑][Link 1]

[北上广深的你，归宿在哪里?][Link 2]

[那些拿命换钱的年轻人，生或死其实没什么所谓][Link 3]

[640_wx_fmt_png_wxfrom_5_wx_lazy_1]: /images/20220607/f82f60bc0da64d93ae27113fc20a8499.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 1]: /images/20220607/e6d200f148da4323bce0142ded546fdb.png
[Image 1]: 
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 2]: /images/20220607/94357ad8cab14dbb8cfae3a017587dfe.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 3]: /images/20220607/b19e9e84b1fb439faf8df6b8d41f3dd4.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 4]: /images/20220607/a7a5a6c22fc94805be7f3a46538a94ef.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 5]: /images/20220607/334cf3c419a94a059a68b93915c802c0.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 6]: /images/20220607/83a56711e584424595bea2dff90fce8e.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 7]: /images/20220607/64a6de8fbc004cc9a1bf821b38028076.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 8]: /images/20220607/24eb431a92564035a9249a0f238fcfbe.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 9]: /images/20220607/94656cf0a5534f20b51ede68b8b0aa5e.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzIwODk1NTYzOQ==&mid=2247483801&idx=1&sn=ec15a187b682ab7217198d8a2cc80fbb&chksm=977a7001a00df917c202464c8dd7acb3fbcc7850e49cb01e6c73e239621d3bb965b92b7625a0&scene=21#wechat_redirect
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzIyMjQ0MTU0NA==&mid=2247484514&idx=1&sn=d6ea293b5275fc72aef3be12a535f628&scene=21#wechat_redirect
[Link 3]: https://mp.weixin.qq.com/s?__biz=MzIwODk1NTYzOQ==&mid=2247483752&idx=1&sn=a5cf433e85d99933200948b275e7cf57&chksm=977a70f0a00df9e627a2b4b544f388d7ed283cb0d7c9db6dd36261afab26b8f7c94e2b72a6a1&scene=21#wechat_redirect