MVC控制器(Controller)与策略模式(Strategy)

MVC模式已经称得上是家喻户晓了，MVC是模型(Model)、视图(View)和控制器(Controller)的首字母缩写。与模型(Model)和视图(View)相比，控制器(Controller)的功能要小得多。正因为它太简单了，MFC甚至把MVC模式简化成文档(Doc)/视图(View) 模式，控制器(Controller)几乎是个透明人，很少有人提及它。

在典型的GUI应用程序中，控制器(Controller)就是事件处理函数，它仅仅是把模型(Model)和视图(View)，或者视图(View)与视图(View)关联起来，一个简单的胶合层而已，如果MVC模型应用得好，控制器(Controller)只有少量的代码，所以常常被人忽视。

在《企业应用架构模式》中，Fowler先生说过，视图和控制器的分离，就不那么重要了。实际上，几乎Smalltalk的每个版本都没有让视图和控制器的实现分离。为什么你会想分离它们呢，经典的例子是支持可编辑和不可编辑的行为。可以在这两种情况下，用一个视图和两个控制器的实现，这里控制器是视图的策略(strateies)。…

可编辑和不可编辑的行为，主要是针对编辑器控制而言的，如果是针对整个窗口，完全没有必要，直接把窗口上各个编辑器设为只读的就行了。真正去写编辑器的机会并不多，在其它地方，用策略模式(strategy)来配置控制器(Controller)的机会更少。我也从来没有关注过控制器(Controller)。这几天在重构短信应用程序时，我发现有时在控制器(Controller)上还真有文章可作。

在我们的平台上，短信应用程序是邮件系统的一个子系统，完整的邮件系统包括短信、彩信和邮件三个子系统。每一个子系统都是一个插件，这样保证了三者的独立性，以便于裁减。短信应用程序基本功能已经可用了，下一步任务是设计彩信应用的架构和编写主要代码，我发现短信和彩信有很共通之处，决定对短信应用程序进行重构。

经过讨论，我们发现彩信和邮件的数据表完全可以统一起来，主要字段(field)有发件人、收件人、收/发时间、主题、状态和附件等等，而短信看似特殊一点，在仔细分析后，可以发现也就多了一个附件而已。当彩信和邮件没有附件时，它们与短信差不多一样，最后我们决定把三者统一起来，放在一张表中。它们的操作也差不多，于是把短信的模型(Model)改成一个通用的模型，在三者间共享。

短信、彩信和邮件的模型部分统一了，缩减了不少的代码。三者的编写和阅读界面差异很大，统一起来的可能性太小，不做统一的考虑了。但是列表界面则完全一样，该界面上的操作无非是删除、删除全部、查看、编写、回复、转发和设置等等，由于模型(Model)是统一的，删除和删除全部等处理完全一样，而查看、编写、回复、转发和设置等，不同的子系统处理不一样，要在控制器(Controller)中调用不同的函数。

列表界面的代码量并不大，但重复三次可不太爽。我决定重用这个视图，用策略(strateies)来配置控制器(Controller)，控制器(Controller)定义了查看、编写、回复、转发和设置等几个接口函数，其实现也很容易，可以直接指向各个子系统的相关函数。其结构如下图所示：

重构之后，处理简化了，几乎没有重复代码，维护更容易。此外还有一个好处是，动态切换子系统速度更快，界面无闪烁。尽管这次重构对短信应用程序的架构做了很大调整，花了好几天时间，但我认为这是值得的。