安卓架构MVC

MVC介绍

1.“MVC” 全名 “Model View Controller”.即 视图层（View)， 控制层（Controller)，模型层（Model)。
他们之间的关系 如图:

View：对应于xml布局文件  //用来数据的显示
Model：实体模型                
Controllor：对应于Activity业务逻辑，数据处理和UI处理  

2、MVC设计图解释
到底上面列出的设计图哪个才是对的。其实都是对的。为什么这么说呢，这得从mvc的发展说起。 
MVC框架模式最早由Trygve Reenskaug 于1978年在Smalltalk-80系统上首次提出。经过了这么多年的发展，当然会演变出不同的版本，但核心没变依旧还是三层模型Model-View-Control。

3、MVC三层之间的关系
箭头→代表的是一种事件流向，并不一定要持有对方，比如上图中model→view的事件流向，view可以通过注册监听器的形式得到model发来的事件。在设计中model view controller之间如果要通讯，尽量设计成不直接持有，这样方便复用。也符合mvc的设计初衷 
在android中三者对应的关系如下： 

视图层(View) 
一般采用XML文件进行界面的描述，这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。

控制层(Controller) 
MVC中Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作，但是因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Actiivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。
 

模型层(Model) 

我们针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作。就可以理解为AndroidApp的Model，Model是与View无关，而与业务相关的。对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。

由于android中有个god object的存在activity，再加上android中xml布局的功能性太弱，所以activity承担了绝大部分的工作。所以在android中mvc更像是这种形式： 

因为activity扮演了controller和view的工作，所以controller和view不太好彻底解耦，但是在一定程度上我们还是可以解耦的。 
 

MVC的小案例

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

2.为了更好的理解MVC，将Activity进行了拆解，提取了一个简单的Controller：

3.点击事件，并且传递给Controller，同时根据Model回调的方法进行UI更新：

 

MVC的缺点

xml的view功能太过于弱化，导致actvity里面即处理业务逻辑，又处理view。这样activity的类的代码比较长。

从上面看起来各个组件的职责视乎还挺耦合MVC的，但是打开Android的一个Activity文件，一看一言难尽， Android中经常会出现数千行的Activity代码，究其原因，Android中纯粹作为View的各个XML视图功能太弱，Activity基本上都是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能过多，代码量大也就不足为奇。所有更贴切的目前常规的开发说应该是View-Model 模式，大部分都是通过Activity的协调，连接，和处理逻辑的。

从上面这个结构来看，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色，直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧！所以，更贴切的说法是，这个MVC结构最终其实只是一个Model-View（Activity:View&Controller）的结构。

 

简单的说：我们平时写的Demo都是MVC，controller就是我们的activity，model（数据提供者）就是读取数据库，网络请求这些我们一般有专门的类处理，View一般用自定义控件。但这一切，只是看起来很美。想象实际开发中，我们的activity代码其实是越来越多，model和controller根本没有分离，控件也需要关系数据和业务。

 

所以说，MVC的真实存在是MC（V），Model和Controller根本没办法分开，并且数据和View严重耦合。