使用MVC模型的几个常见误区

像名片、日程、任务、短信、文件浏览器和多媒体播放器等应用程序，都采用MVC模型作为其基本架构。但从这段时间的文档评审来看，我们对MVC模型的理解仍然存在一些误区。这里简单谈一谈，欢迎交流。

先说两句题外话，免得少数网友替我着急。他们会说，拜托，你写点新内容好不好，不要用MVC这类老掉牙的东西来充数。呵，很多人都热衷于新技术，我 以前也一样。经过五六年的学习和实践后，让人遗憾的是，我没有发现什么真正的新技术。相反，倒是一些”老”技术充满魅力。包括像汇编语言、C/C++、 awk/bash、计算机组成原理、操作系统原理、数据库原理、编译原理、数据结构、TCP/IP实现、面向对象、设计模式、POSA、代码重构、自动测 试、人机交互，RUP/XP等比较通用的知识，也包括像linux、apache、xerces/xalan、GTK+/X/glib、STL /boost、MFC、COM/DCOM等这样特定平台/函数库。根据自己的经验来看，了解一项技术的基本内容并不难，难点在于灵活应用它们，在于适当的 时候选择适当的技术。个人认为，把目前这些”老”技术掌握好了，无论是设计还是编程，完全可以做到游刃有余的境界(我还在努力中)。相反，整天只关注所谓 的新技术，对一些经典技术反而只了解皮毛，可以说是捡了芝麻丢了西瓜，得不尝失。道不同不相与谋，热衷于新技术的朋友可以在此打住了。

好了，言归正传。下面是我在我们平台中发现的一些问题：

1. 把控制器(Controller)和模型(Model)混在了一起。MVC模型的三大部分中的控制器(Controller)是最容易让人混淆的，在基于 窗口的GUI应用程序中，控制器(Controller)一般就是控件的事件处理函数。控制器(Controller)有两个基本功能，一是把用户从界面 上的操作(点击按钮)映射成模型(Model)对应的功能(如删除数据)，二是把模型(Model)的变化更新到视图(View)上。控制器 (Controller)和视图(View)的耦合比较紧密，尽管可以用策略模式来实现多个控制器(Controller)之间的切换，但那样做，实现复 杂而且没有多少好处，所以很少有人去分离控制器(Controller)和视图(View)（据说WEB开发例外）。然而Glade把产生的事件处理函数 放在callbacks.h/.c中，把产生的界面代码放在interface.h/.c中，这看似把界面与实现分离了，使得一些同事误以为 callbacks.h/.c中的代码就是模型(Model)，所以把控制器(Controller)和模型(Model)混一起了。结果是模型 (Model)包含了一些控件，没有做到与界面的分离。

2. 所有界面与模型(Model)关联。有的界面是比较独立的，完全可以以一种调用关系来实现，结果也与模型(Model)挂了钩。这看似充分利用了模型 (Model)，实际上是把模型(Model)当成了全局变量的替代器。结果是一方面增加了界面与模型(Model)耦合，让这些独立的界面难以重用，同 时也增加了模型(Model)复杂度。

3. 认为一个应用程序只能有一个模型(Model)。大部分应用程序都只需要一个模型，但一些同事把这个现象这看成了定论。其实模型(Model)是一个逻辑 上的概念，如果几个视图和另外几个视图毫无关联，最好各自使用独立的模型(Model)。否则把多个模型(Model)绞在一起，造成不必要的耦合，使用 代码重用困难，也让增加模型(Model)的复杂度，使实现的难度增加。

4. 认为模型(Model)是一个不可再分的单元。在一些设计中，界面无关的实现代码的确与界面代码分开了，但它们都放在模型(Model)里，模型 (Model)成了一个庞然大物。我们说了，模型(Model)只是一个逻辑上的概念，甚至完全可以没有模型(Model)这个名字出现，其架构仍然是基 于MVC的。模型(Model)的责任一般要进一步划分，把责任分配多个更专业的类上。否则模型(Model)会过于复杂，使实现的难度增加。