思想还是有帮助的[4]。

在PHP中用Smarty实现Template View是比较好的方法，它所使用的模板文件是一种HTML和特定标识符的混合。这些标识符不仅仅是变量的替换，而且还可以表示一些简单的逻辑应用。有人曾经怀疑Smarty作MVC视图的适用性，因为MVC强调严格的表现层与逻辑层的分离。而Smarty在模板中加入逻辑应用仅仅是显示上逻辑判断，与业务逻辑没有任何关系。这样一来，不仅彻底地实现了程序代码与HTML代码的分离，而且更加符合MVC―分离‖的思想。

需要注意的是，Smarty所谓的―编译‖实际上是把数据和HTML组合成最原始的嵌套模式，即仅是echo语句与HTML的组合，以提高效率。 b. Transform View：

Transform View从Model中提取数据，然后把数据转换成需要输出的格式。它实际上是使用一种语言逐个遍历数据元素，然后集中输出。Template View与Transform View之间的差异就是数据流的方向。在Template View中先有一个输出的框架然后向里面插入数据。Transform View中则从数据着手，从它之中建立输出。实施Transform View的主要技术是xslt。 （2）控制器

为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接受请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。

用户控制器提供一个控制和处理请求的集中入口点，它负责接受，截获并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。

按照传统做法，我们需要在Controller里使用请求捕获者类和分发者类。请求捕获者类捕获HTTP请求转发给控制器。但在实际应用中，特别是小型应用中，只要实现其思想即可，例如，PHP中的系统变量$_REQUEST, $_POST, $_GET，$_FILES就包含了所有的可能的用户请求，安全方面可以对其进行过滤(filter)和判断，实现请求捕获者类的功能。至于分发类者，则主要有两种实现方式： a. Switch…Case：

45页

此种方法使用一系列的常量作为判断依据，实现Action与Model的对应关系，但缺陷是有可能使得Controller过于庞大。 b. Action Map：

这是一个比较常用的方法，通过对数组键与值的判断，使用一个相同的命令模式调用不同的Model。

总之，MVC并没有严格的定义，它的思想有很多实现方法，灵活应用是使用MVC的一个原则。 （3）模型

MVC系统中的模型从概念可以分为两类——系统的内部状态和改变状态的动作。模型提供了业务实体和业务处理，即实时把―做什么‖和―如何做‖分离，目的就是尽可能的实现代码重用。

模型是MVC的关键，在设计模型时需要对业务流程和数据对象有着充分的理解，在此基础上尽可能的抽象出全部模型的搭配。模型与模型之间应是互异的，不仅在业务逻辑上，在数据对象上也应如此。另外还要对某些暂时未实现的功能留有接口，易于升级和维护。

PHP中模型的实现可以用函数也可归为类，自由度很高。数据模型的关键是与数据库的接口，接口要尽可能的做到统一。目前常用的就是ADODB和PDO，这两种仅仅是做到了数据库应用与数据库种类的无关性；在Zend最近推出的Zend Framework中，其Zend DB控件对数据库又进行了上一层的封装，有的时候只要设置几个参数即可，用户完全可以不用参与到具体SQL语句的编写上。

7．4 三层开发体系与MVC的比较

传统的三层开发体系结构将所有业务分为三层，即表现层、逻辑层和数据层。这样的开发结构同样实现了程序代码与HTML的分离，表现层与逻辑层的分离。分离是好的，但传统三层体系结构往往忽视了三者之间的内在联系，它们之间如何协调也并不清楚，而且逻辑层如何具体实现业务以及与业务对象之间的关系也并未表明。

MVC在一定程度上弥补了三层开发体系结构的不足。MVC具有多视图对应一个模型的能力，对多种不同方式的访问请求可以用一个模型来实现，减少了代

46页

码的重复和维护量，一旦模型改变也易于维护。其次由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。

再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规划的改变只须改动MVC的模型层。

控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此控制层可以说包含了用户请求权限的概念。

但是MVC也存在着一些缺点，例如代码数量的增加，其次是MVC并没有一个严格的定义，实现方式上百家争鸣，有一定的混淆，而且实现成本上也高很多。但这是相对的，一般而言，项目越大，MVC的优势越明显。

7．5 MVC的开发流程

在着手开发一个Web项目时，数据库的设计通常是第一位要做的，基本上所有的操作都会涉及到数据表的操作。那么数据表的设计就关系到整个项目的设计和功能的实现。

如果数据表尚未给出或者需要根据项目的目标来设计的话，那么首先要做的就是功能分析。说到功能，与之联系最为紧密地就是用户界面，作为人机交互的桥梁，它的重要性不言而喻。用户在使用程序时只关心怎么完成要做的事情以及程序的易用性，对具体如何实现并不关心。所以设计用户界面的一个重要原则就是隐藏所有与用户无关的，以最简捷的方式提供给用户最需要的东西。UI和MVC中的View在实体上是等同的，却完全是两种不同意义上的概念，一个对于用户来说，一个对于开发人员来说，因此，UI的设计还需要考虑对开发的影响。基本的原则就是尽可能的使一次操作所涉及的数据表更少，功能尽可能的集中并且独立，以更好利用模型的重用性。

基于这种理念，MVC的设计应该是这样一种顺序，Functions-UI-View-DB Table Structure-Business Logic(Model)，即首先确定功能，根据功能合理的确定用户界面进而为MVC中View划下一个合理的轮廓。然后再根据功能的集合划分来设计数据表。

在MVC中，View和数据表应该是整个规划过程的两个端点，View是最形象最贴近用户的，数据表是最抽象最底层的。所以，一旦两个端点确定，中间就

47页

是确定如何从起点到终点的过程，即逻辑模型的实现。这就好比在一个范围内，有目标的去工作，不会超轨，也不会偏离最终目标，是一个比较好的设计方法。同时，对于View和数据表的规划就有了更高的要求，可以在着手开发项目之前，反复对View和数据表进行调节平衡，目的是减少开发的复杂性。

对模型的开发，基本上使用Object Oriented思想，找到相关的对象，以适当的粒度将他们归类，再定义类的接口和层次，建立对象之间的基本关系。所以模型设计应当有针对性，同时对将来的问题和需求也要有足够的通用性。要一下子就得到复用性和灵活性好的设计，是非常困难的。所以这是一个反复修改和调试的过程。

48页