聊聊Android中的三大框架

       为什么我们要用到开发模式,如果单单说写一些Demo或者一个工程只有几个Java文件,其实也没有别要去想太多的架构问题,直接撸代码就完事了。但是如果一个项目代码量比较多、业务比较繁琐、扩展性高。那么我们前期的规划是必不可少的,更加需要我们关注架构层面。

接下来我们看下Android现有的几大架构

一、MVC————Model-View-Controller

M:Model(模型)   M层是用来处理数据以及业务逻辑关系

V:View(视图)   V 层是用来数据的显示

C:Controller(控制器) C 层是把M和V之间的桥梁

在Android开发中,Activity本身并不是一个标准的MVC模式中的Controller,它的首要职责是加载应用的布局和初始化用户界面,并接受并处理来自用户的操作请求,进而作出响应,这样就会难免出现在Activity去处理数据。在数据处理和业务逻辑越来越多的情况下,View也就是Activity或Fragment就会很臃肿,代码量蹭蹭的往上涨,不太利于后期的开发和维护。这就会我们引进MVP。

  • 举个例子:

比如说我们要实现这样的一个功能,当点击“登陆”按钮时,查询自己的账号余额。

对于MVC 实现,应该是这样的:

  1. 先定义一个 model,需要有通知View更新的能力,在model加载成功以及获取数据之后,通知View进行UI更新:

  2. 为了更好的理解MVC,将Activity进行了拆解,提取了一个简单的Controller:
  3. 点击事件,并且传递给Controller,同时根据Model回调的方法进行UI更新:

二、MVP  ————  Model-View-Presenter

M:提供数据

V:显示数据

P:处理逻辑

其实MVP就是MVC延伸出来,同样是划分三层,不过MVP的Presenter让Activity更加专注于处理页面显示。这样做的好处就是:让Activity只做UI的处理,数据处理和业务逻辑全丢给Presenter来完成。但是有个缺点就是我们要写很多的接口类,增加代码量。

还是上面的例子,我们使用MVP进行改写:

  1. 先对MVCModel进行封装,通知Presenter:                            
  2. 再定义Presenter ,逻辑处理,然后通知View更新UI:
  3. 对于Activity,把Model对象变成Persenter:

三、MVVM ———— Model-View-ViewModel

M:model  实体模型

V:view  UI交互层(Activity、fragment)

VM:ViewModel  负责View与Model之间的交互,业务逻辑处理

首先MVVM是一种模式,而实现这种模式的就要用到Data Binding(关于这个可以在网上搜索学习,这里不多介绍)。然后View和ViewModel是可以通过Data Binding来实现视图和数据的双向绑定,从而达到MVVM这样的效果。

  • 例子暂无

 对于个人来言,我更倾向于使用MVP模式来作为开发,不过这些都是相对于项目的难易程度来说的,不能一味死板套公式,灵活应变才是硬道理。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页