Android MVC 结构

MVC模式的简要介绍

MVC是三个单词的缩写，分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑。 View层用于与用户的交互。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。

Android框架期望开发者们将Activity基础类作为UI处理，这也就意味着一个Activity需要负责视图与控制器两个部分的任务。

Android采用了典型的MVC结构。其表现如下：

View既可以通过xml(layout目录下)生成，也可以通过硬编码的方式直接通过代码生成。对于xml中的View资源，可以在代码中通过getViewById()的方法获得。

Model既可以通过xml(values目录下)生成，也可以硬编码的方式直接在代码中指定。View和Model通过Adapter来进行连接。典型的Adapter包括ArrayAdapter(可以Sort()操作)、CusorAdapter(从Cusor中查询到数据源),ListAdapter、SimpleAdapter(最常用)、SpinnerAdapter(它是一个接口，设置Spinner应用SimpleAdapter的setDropDownResource方法)。

那么究竟该如何划分这几层结构呢？我觉得可以换个思路出发，我们究竟该如何合理地组织一个Android应用程序呢？

1. xml布局负责将界面布局做好，并且尽量做到合理分割与减少层次
2. Activity做好控件事件绑定与业务流程控制
3. Intent做好Activity间的session传递管理
4. 自己创建Model（可以通过Observer模式进行绑定处理、并且包装好各种provider）将处理数据的工作做好。不建议简单地将各个数据字段散乱地存放在Activity周围，而是借助数据Bean的思路存放在Model下面，这样在Model数据项变得庞大后难于管理与重构，而且这多为非面对对象的设计方案。
5. Adapter是数据与呈现的粘合剂

注意事项:

1、Controller绝对不要对外暴露方法，不要让其它C可以通过函数调用的方式操作自己。

这个是严重破坏Controller生命周期自管理的行为，必须禁止。对一个C来说，接受外部C的启动参数并启动，加入到系统的C管理器之后，就不能接受任何其它C的驱动了。如果确实需要通信，请使用消息。

2、消息通信。

这个应该必须被当作是C之间进行通信的唯一手段，因为只有它是不干涉C的运行的，由目标C自己决定是否接收消息，接收了消息之后如何处理。一个Ca启动另一个Cb，或者在Cb运行期间，Ca向Cb发送消息。Activity、Fragment中的Intent，ViewController中的Notification，这些都是多少天然的组合。

3、当Controller之间有共性的时候，我们肿么办？

这其实是个Has-a，还是Is-a的问题。我用近10年的编码经验告诉大家，一定要选择Has-a，这个基于几点，一个是业务多变化，今天的共性明天可能就不存在了，今天有3个，明天就可能变成2个，选择Is-a这种强关联，会很痛苦的。另外，业务层的开发往往是几个人几杆枪，任务分开各干各的，Has-a是最合适的，把关键的公共小模块做好，其它的自由发挥去吧。不要把眼睛紧盯在那几行重复的代码上面。

4、页面太多，Controller之间跳转混乱，怎么破？

这个其实是表象。首先，我们做好上面3点之后，C之间的耦合性问题已经不存在，接下来我们再规范一下C之间进行跳转时的传参规则，参数由目标C来定义自己需要接收的数据格式。想跳到哪个页面时，找到它的源码，看下它定义的参数规则，按它的要求传过去，然后把生成的新C交给系统的C管理器就好了。在Android中是startActivity，commitFragment，IOS中是presentViewController。

5、关于页面开放。是否使用PageLink？

这个要避免走向极端。如果你的页面需要开放给第三方应用，毫无疑问，PageLink是最好的选择。因为这些页面一般都是核心页面，稳定性高，数量少，参数少，一个URI可以很清晰表达出来。像电端类的宝贝详情，SNS类的个人主页、日志详情等。那对于内部页面之间的跳转呢？这个要慎用。内部页面数量多，参数多变，数据结构复杂多样，随着业务的变化还会不断更新。每次跳转前把数据结构压成URI，通过分发中心传递给目标C之后再反序列化，校验参数合法性。每次参数有变化再调整，你累不累？