第十七章 MVC 模式
web应用是十分多样化的，为了实现某种应用，那哪种或哪些是最好的呢？或者说，对于web应用有没有一种最好的体系？
问题
你能配置一个单一的web体系去满足每个普通的web应用吗？包括一般性的界面呈现风格,身份验证，表单数据确认等等？
解决方案:
MVC模式把你的软件组织架构分解成3个清晰的任务
model结合了应用数据，应用流程以及业务逻辑
view从model中提取数据并呈现出来
controller调用应用流程，接收输入并传送给model和view
注：MVC的起源
MVC模式是1970年由trygve reenskaug在施乐公司的研究中心提出的。最早的参考例程代码是用smalltalk80编写的。它最初是用来解决应用软件中的用户图形界面的交互问题的。
你要使用了MVC模式，你就会知道它是多么的有用，尤其是对于图形化的用户界面应用。除此之外，MVC对web应用也非常有用，虽然web服务进行通讯连接，与通讯过程有时会中断，但这也带来了一些独特的挑战和机会。
假如你到这一章来寻找一种真正的对于web应用的MVC方法，我希望你不会对于这里的答案太失望。最完美的解决方案是不存在的，但是这里有很多实例以及相关的模式，帮助你有效的去实施MVC。有希望的是，这里的观点能作为你的编码工作的跳板，并且带领你进行更多的研究。
模块视图控制器
不像其他的设计模式，MVC模式不是一个注重于讲述一种可以直接设计编码的类结构的模式。相反，它不仅仅是概念上的指导或范例。
在概念上，MVC模式的定义的是model，view以及controller三者之间的桥梁。controller以及view都依赖于model，因为view和controller都得向model发送数据请求。数据通过controller输入到你的系统当中，并最终通过view显示出结果。对于你一个php开发者，更具体的来说，controller处理每一个外部的http请求，而view将产生http回应。
下边是MVC模式的定义图
require_once ‘Smarty.class.php’;
$tpl =& new Smarty;
$tpl->assign(array(
‘title’ => ‘Colors of the Rainbow’
,’colors’ => array(‘red’, ‘orange’, ‘yellow’,
‘green’, ‘blue’, ‘indigo’, ‘violet’)
));
$tpl->display(‘rainbow.tpl’);
rainbow.html的自定义语法就像：
<html><head>
<title>{$title}</title>
</head><body>
<h1>{$title}</h1>
<ol>
{section name=rainbow loop=$colors}
<li>{$colors[rainbow]}</li>
{/section}
</ol>
</body></html>
wact(http://wact.sf.net/)效仿了martin fowler在poeaa中概述的那种自定义标签。虽然wact支持一个与smarty相似的自定义语法作为快捷方式，wact的自定义标签列阵如下：
require_once ‘wact/framework/common.inc.php’;
require_once WACT_ROOT.’template/template.inc.php’;
require_once WACT_ROOT.’datasource/dictionary.inc.php’;
require_once WACT_ROOT.’iterator/arraydataset.inc.php’;
// simulate tabular data
$rainbow = array();
foreach (array(‘red’, ‘orange’, ‘yellow’,
‘green’, ‘blue’, ‘indigo’, ‘violet’) as $color) {
$rainbow[] = array(‘color’ => $color);
}
$ds =& new DictionaryDataSource;
$ds->set(‘title’, ‘Colors of the Rainbow’);
$ds->set(‘colors’, new ArrayDataSet($rainbow));
$tpl =& new Template(‘/rainbow.html’);
$tpl->registerDataSource($ds);
$tpl->display();
rainbow.html的模版如下：
<html><head>
<title>{$title}</title>
</head><body>
<h1>{$title}</h1>
<list:list id=”rainbow” from=”colors”>
<ol>
<list:item><li>{$color}</li></list:item>
</ol>
</list:list>
</body></html>
在这个wact例子里有相当多的包含的文件。这是因为框架有各种各样的要素来处理网站应用问题的各个部分。只需包含你需要的元素。在上面的例子中，模板就是一个View，dictionary data source 作为model的代理，php脚本本身是作为一个controller.许多自定义标签设计成与表格数据一起运用--像你从数据库中提取的记录集---转换成简单数组以后把它用在模版里。
最后一个样式是拥有一个模版的有效的xml文件，使用各自的要素的属性作为目标替换你的模版。这里有一个是用PHP- TAL的技术实例（http://phptal.motion-twin.com/）
// PHP5
require_once ‘PHPTAL.php’;
class RainbowColor {
public $color;
public function __construct($color) {
$this->color = $color;
}
}
// make a collection of colors
$colors = array();
foreach (array(‘red’, ‘orange’, ‘yellow’,
‘green’, ‘blue’, ‘indigo’, ‘violet’) as $color) {
$colors[] = new RainbowColor($color);
}
$tpl = new PHPTAL(‘rainbow.tal.html’);
$tpl->title = ‘Colors of the Rainbow’;
$tpl->colors = $colors;
try {
echo $tpl->execute();
}
catch (Exception $e){
echo $e;
}
rainbow.tal.html的模版文件如下
<?xml version=”1.0”?>
<html>
<head>
<title tal:content=”title”>
place for the page title
</title>
</head>
<body>
<h1 tal:content=”title”>sample title</h1>
<ol>
<li tal:repeat=”item colors”>
<span tal:content=”item/color”>color</span>
</li>
</ol>
</body>
</html>
当然，所有的解决方法都是将model数据的显示从model以及应用程序本身分离出来。每个前期的实例都是实质上产生了同样的内容，所以选择哪个是个人喜好的问题。
Transform View
变换视图从你的model中提取数据，然后把数据转换成需要输出的格式。它实际上是使用一种语言逐个遍历你的数据元素，然后集中输出。
模版视图与变换视图之间的差异就是数据流的方向。在Template View中你先拥有一个输出的框架然后向里面插入domain数据。Transform View中则从数据着手，从它之中建立输出。
实施Transform View的主要技术是xslt.
Controller
controller是MVC里的一个角色，很多php MVC框架都讲到了。主要是出于这样的考虑：model对于应用是特定的，而几乎每个开发人员都已经有他们喜爱的模版引擎，它是视图的一个主要要素。那使得解释http回应，控制申请流（采取适当的行动来显示），两个关联的任务合为一个通用框架。
Front Controllers
它常常有助于集中控制应用流于一点。集中化可以帮助你了解一个复杂的系统是怎样运行的，以及提供你一个可以插入全局代码的空间，比如一个Intercepting Filter模式。对于集中化，Front Controllers对于集中控制的系统是很好的选择。
注：intercepting Filter
intercepting Filter模式是gof书中的Chain of Responsibility模式的一个实例。它考虑了运用普通任务的连续处理请求，譬如记log和安全。
这有两个普通的实例。一是在某个链中连续使用补空格直到到达application controller，另一个类似于一系列的油漆工，有助于前后的补空动作。（考虑移除空白或者一个压缩的filter,你可以在预处理输出缓存，在加工后执行你的filter）
作为一个简单的实例，一个Intercepting Filter和一个Front controller联合起来会是怎么样，假设我们有perfilter()以及postfilter()两种方法用于我们的filter接口。然后我们可以使用一种方法把filter加到我们的Front controller.
class FrontController {
var $_filter_chain = array();
function registerFilter(&$filter) {
$this->_filter_chain[] =& $filter;
}
}
在运行实际的Front controller工作之前（产生页面，分派等等），我们可以在序列中使用prefilter()方法，在Front controller完成了它的任务后，postfilter（）方法可以在相反的顺序调用。
class FrontController {
//...
function run() {
foreach(array_keys($this->_filter_chain) as $filter) {
$this->_filter_chain[$filter]->preFilter();
}
$this->_process();
foreach(
array_reverse(array_keys($this->_filter_chain)) as $filter) {
$this->_filter_chain[$filter]->postFilter();
}
}
function _process() {
// do the FrontController work
}
}
Application controller
Front controller通常代替了Application controller，而Application controller模式才是MVC controller的核心所在。controller的首要责任就是决定应用程序要做些什么来响应请求。
实现controller的最典型的方法就是使用命令模式。命令模式包含了对象中的一个动作，这样你就能用参数表示一个请求，写入请求队列，记入日志，或者支持操作（例如一个撤销动作）。在web应用的上下文关联中，分派给命令模式并完成一个特殊的http请求作为代码的目标是有用的。本质上，命令模式让你中止你的应用和代码的不连续行为，每个作为一个小的，便于管理的类，用一个相同的api使controller分派到一个明确的具体命令来实现需要的应用功能。
不要让强加的过多关于controller以及分派的叙述混淆你。如果你已经花了甚至几个小时在php上，那你可能已经写了一些Application controller. 比如，一个简单的传递回给它自己的表单，比如.....
if (count($_POST)) {
// do form handling code
} else {
// display the form
}
....是一种Application controller形式。稍微有点复杂的Application controller像以下的：
switch ($_POST[‘action’]) {
case ‘del’: $action_class = ‘DeleteBookmark’; break;
case ‘upd’: $action_class = ‘UpdateBookmark’; break;
case ‘add’: $action_class = ‘InsertBookmark’; break;
case ‘show’:
default:
$action_class = ‘DisplayBookmark’;
}
if (!class_defined($action)) {
require_once ‘actions/’.$action_class.’.php’;
}
$action =& new $action_class;
$action->run();
另一种可能实现分派的方法就是：用一个配置装载一个联合的数组。你可以如下方式作为结尾：
$action_map = array(
‘del’ => ‘DeleteBookmark’
,’upd’ => ‘UpdateBookmark’
,’add’ => ‘InsertBookmark’
);
$action_class = (array_key_exists($_POST[‘action’], $action_map))
? $action_map[$_POST[‘action’]] : ‘DisplayBookmark’;
if (!class_defined($action)) {
require_once ‘actions/’.$action_class.’.php’;
}
$action =& new $action_class;
$action->run();
根据我在web应用方面的经验显示，一个双分派结构可以成为一个有用的mental map用来比较框架间依赖的分派装置。第一个调度是一个需要用你的model来进行的动作。在一个可见的动作之后，发出一个http跳转指令指示客户端去取得一个特定的View。第二个调度就是选择一个特定的View。（在这种方法的早期程序中，我使用了一个条件语句，但MVC实例本身对使用Command pattern进行调度）
model--view--controller程序表的“真实生活”版本看上去与上面显示的“理想”的程序表非常相似。主要添加的是actionfactory引起每个动作，那是一个具体的命令。
在很多我开发的MVC运行程序中，第二个调度以默认ShowViewAction进行。
这个图显示了第一个调度创建了一个具体的指令ShowViewAction.这个动作反之会使用ViewFactory来创建一个具体的View类，Martin Fowlerj将的MVC关于View的PoEAA部分叫做View Helper。这个视图可以使用你喜欢的模版引擎来选择和解析一个模版文件，填充模版变量：从model取得数据，进而通过模版呈现结果返回给客户端。
这是一种可以提升MVC名誉的图，但是实际上，这张图的各个要素都被添加了，以满足通过组织代码使得维护变简单的需要。
总之，我发现了使用一个特定的框架最显著的障碍就是了解一个框架是怎样运行的以及怎样添加有特殊用途的功能。实际的组织是典型的一次性简单了解，但是起初在没有上下联系的情况下它似乎又很难理解。
贯穿MVC的相关问题：
似乎有很多“什么到哪里”的问题围绕着MVC,你会从不同的MVC拥护者那里收到很多不同的答案。
$_SESSION属于哪里？一个争议是说sessions是不变的数据存储，通常是以文件形式保存在服务器上，因此最好归入model的范畴。第二种说法就是session和其他的php superglobal一样，session数据是输入系统的，因此是属于controller，另外一些开发员认为，sessions是用cookie执行的，一种工作在http上的html里的技术，所以是和view相关联的。
身份认证是属于哪里？它似乎像是应用逻辑的一部分，因此是属于model。但是如果你要限制只有通过验证的用户才能执行特定动作（controller的部分）呢？好，controller可以进入model，所以身份认证归入这里似乎是个完美的划分。但是http认证呢？它也进入到controller吗？
在整个概念中浏览器适合在哪里？很明显是View，对吗？如若你想通过java语言进行验证呢？验证不属于controller和model码？你怎么让它进入View呢？
这些争论都没有平息的迹象，当你在你的MVC实现中试图找出怎么样看待这些你关心的问题时以上每个都导致了一些挑衅的想法。
不含MVC的框架
很明显不是每个框架都围绕着嵌入在MVC模式的想法的分离上。这里是一个关于无MVC的框架想法的小例子
事件处理
当你在gui环境下工作时，工具一般设置成响应事件。想想button.click().一些php框架试图采取这种为核心思想。在zend的php5编程比赛中认识了prado，它把事件处理作为核心概念。WACT使用Composite pattern来综合controller的概念，每个都有“监听程序”，它能接近事件处理透视图。
控制容器的反向
在java圈子里的一个热门话题就是控制容器的反向(ioc),亦称Dependency Injection pattern。一个好的介绍这个模式的文章在 http://www.martin- fowler.com/articles/injection.html.
这个模式结合了一个类似Pico的Dependency Injection容器和类似WACT的MVC框架，用以构建一个“autowires”自身的应用，这一模式是是与MVC正交的──这是一个我非常感兴趣的领域
结束语
这里是一个简短的MVC相关设计模式的导航.如果你想寻找完整的PHP下的MVC开发框架，我推荐你看Mojavi（http://www.mojavi.org/）；这是一个很好的MVC示例,并且这个项目的开发很活跃，社区也比较有活力。
这一章也许没有能够解决你在web架构方面的任何具体问题，希望能够给你提供一些参考，能够成为你展开相关研究的一个起点,或者能够为你在编写能为PHP开发带来巨大变革的Magic Web Application Architecture时带来一些灵感。