2.2　Android与MVC设计模式

如图2-3所示，应用对象分为模型、视图和控制器三类。Android应用基于模型-视图-控制器（Model-View-Controller，MVC）的架构模式进行设计。MVC设计模式表明，应用的任何对象，归根结底都属于模型对象、视图对象以及控制器对象中的一种。

• 模型对象存储着应用的数据和“业务逻辑”。模型类通常用来映射与应用相关的一些事物，比如用户、商店里的商品、服务器上的图片或者一段电视节目，在GeoQuiz应用里就是地理知识问题。模型对象不关心用户界面，它的作用是存储和管理应用数据。

  在Android应用里，模型类通常就是我们创建的定制类。应用的全部模型对象组成了模型层。

  GeoQuiz应用的模型层由Question类组成。

• 视图对象知道如何在屏幕上绘制自己，以及如何响应用户的输入，比如触摸动作等。一条简单的经验法则是，只要能够在屏幕上看见的对象，就是视图对象。

  Android自带很多可配置的视图类。当然，你也可以定制开发其他视图类。应用的全部视图对象组成了视图层。

  GeoQuiz应用的视图层由res/layout/activity_main.xml文件中定义并实例化后的各类部件构成。

• 控制器对象含有应用的“逻辑单元”，是视图对象与模型对象的联系纽带。控制器对象响应视图对象触发的各类事件，此外还管理着模型对象与视图层间的数据流动。

  在Android的世界里，控制器通常是Activity或Fragment的子类（第8章将介绍fragment）。

  GeoQuiz应用的控制器层目前仅由MainActivity类组成。

图2-4展示了在响应诸如点击按钮等用户事件时，对象间的交互控制数据流。注意，模型对象与视图对象不直接交互。控制器作为它们之间的桥梁，接收对象发送的消息，然后向其他对象分发指令。

图2-4　MVC数据控制流与用户交互

使用MVC设计模式的好处

随着应用功能的持续扩展，应用往往会变得过于复杂而让人难以理解。以类组织代码有助于从整体视角设计和理解应用。这样，我们就可以按类而不是按变量和函数来思考设计问题了。

同理，把类按模型层、视图层和控制器层进行分类组织，也有助于我们设计和理解Android应用。这样，我们就可以按层而非一个个类来考虑设计了。

GeoQuiz应用虽不复杂，但以MVC分层模式设计它的好处还是显而易见的。接下来，我们会升级GeoQuiz应用的视图层，为它添加一个NEXT按钮。你会发现，添加NEXT按钮时，可以不用考虑刚才创建的Question类。

MVC设计模式还便于复用类。相比功能多而全的类，功能单一的专用类更有利于代码复用。

举例来说，模型类Question与用于显示问题的部件毫无代码逻辑关联。这样，就很容易在应用里按需使用Question类。假设现在想显示包含所有地理知识问题的列表，很简单，直接利用Question对象逐条显示就可以了。

对于GeoQuiz这样的简单小应用，MVC模式很合用。然而，当应用更大、更复杂时，控制层很可能也会随之膨胀，变得非常复杂。一般来讲，开发人员希望让activity和控制器轻量些，让activity尽量少包含一些业务逻辑。如果使用MVC模式无法让应用控制器保持轻量，那么就该考虑替代方案了，比如采用MVVC设计模式（详见第19章）。