编码对于合格的PHP程序员来说并不是什么难事（也许只是花费时间长短的问题），因此系统分析和设计这一阶段就显得尤为重要。不过本文并不打算讨论和需求分析、获取商业逻辑相关的话题，而是针对系统设计方面进行探讨。
面临难题
编码对于合格的PHP程序员来说并不是什么难事（也许只是花费时间长短的问题），因此系统分析和设计这一阶段就显得尤为重要。对于一个担任PHP项目的系统分析员来说，面临着两个难题：

PHP语言本身的限制。
这一点在复杂系统的面向对象设计中尤其显著。PHP的面向对象特性在现有版本中虽然得到了改善，但是还不甚健全，根本不足以担任面向对象设计的实现语言；即使眼光长远一些，在即将释出的以Zend Engine 2.0支持的全新PHP中，面向对象特性也不会像现在流行的Java或者C++那样（关于这方面的内容可以参见我在developerWorks中国网站发表的另一篇文章）。但是如果采用完全面向过程（准确说是面向Web页面）的方式，可以想见整个系统的设计会非常复杂，而由此带来的编码复杂和维护困难更加难以应付。
现有资料的严重缺乏。
这是众所周知的现象即针对Web项目的系统设计资料不足；而在这些有限资料中，关于PHP的设计资料又非常匮乏。如果本公司或本人也没有相关的技术积累，系统分析员只能在黑暗中摸索方法（更坏的两种情况，一是照搬其他项目比如Java或者C++的设计，二是认为项目简单而不负责任的草草了事）。



认识面对的系统
既然如此，采用何种方法妥善处理PHP系统的分析和设计？最初的构想应该需要分清项目承担任务的类型：

涉及大量客户本身或者客户所在行业的商业逻辑的项目，包括办公系统、订单系统以及其他商业系统。
简单网站项目，包括一些需要承担高访问量或要求快速响应的项目比如品牌网站或者活动网站以及其他一些网站。
综合性网站项目。通常包含多个相对独立的子系统比如新闻子系统、论坛子系统、产品陈列子系统等等。



PHP的设计初衷在于解决后两种项目的迫切需求，语言本身对于这些项目进行了良好的改造。而众多的PHP开发者对这些项目也具有或多或少的经验，相关书籍中的范例也大都围绕于此。相对说来第一种系统所有的资料不多，各种出版物对其内容也很少提及。因此在本文中将题所述对第一种类型的项目进行详细讲述（有关MVC模式和类封装），同时附带提及第二种项目（有关黑客代码）以及第三种项目的设计方法。当然，并不是被归类的这些项目就只能采用本文描述的方式，系统分析员需要权衡各方面因素加以选择。

方案一：涉及大量商业逻辑项目
如何分离用户界面和后台操作？如何避免将商业逻辑混淆于一般的流程控制中？作为一个严谨的商用项目，就需要考虑很多类似的问题。对于由PHP担当的这类项目，贯彻Model-View-Controller（MVC）模式的设计是一个非常好的方法。

理论描述
在这里我不想多加解释MVC模式本身--简单的从字面上以及应用上说，通过将系统的设计分为Model模型/逻辑、View视图/界面、Controller控制/流程三个逻辑部分达到良好的项目效果，以此便利各部分开发者的工作并降低日后的维护成本。（如果您熟悉JSP开发的Model 2模式，可以发现它也是MVC模式的很好体现。）就现实的项目开发而言，现存的很大问题包括网页设计人员和程序开发人员的工作交错和冲突以及商业逻辑嵌入页面造成不可重用也很难维护等等。引入MVC模式一方面可以为系统的总体设计指出明确的方向，对于开发团队的分工也是良好的指导。

既然依照MVC模式要求对系统的总体结构在逻辑上分成三部分，那么团队的开发者中也存在着针对各个部分的开发者。

开发者角色 相关系统逻辑 职责
网页设计人员 View视图/界面 设计所有用户界面的网页模板。
控制流程开发人员 Controller控制/流程 编写系统流程中的所有PHP页面。
商业逻辑开发人员 Model模型/逻辑 开发系统设计中规定的各个类（其中的方法）。



由以上的表格可以看出，传统的网页设计和程序开发的人员分工被打破而取而代之的是根据系统逻辑划定的职责。对于网页设计人员，职责并没有改变，准确说由于这样的划分避免了以往与程序设计人员的纠纷，他们完成的只是网页模板，因此只需关注于纯粹的网页代码（主要是HTML，也许会有其他客户端的代码比如WML之类）而根本不需要被服务器端的<? … ?>干扰。程序设计人员则被分为两部分：其中比较容易把握的是商业逻辑开发人员，他们的任务是根据系统分析员给定的模块（准确说是类方法）完成之，在他们手中的PHP更像一般的程序设计语言（比如Java）而与Web没有什么关系；一时较难接受的是控制流程开发人员，他们的任务是在实现系统设计时制定的系统流程的同时，根据客户端的输入调用商业逻辑（相应的类方法）以及输出更新的界面（对设计网页模板进行处理），在他们手中PHP可以充分发挥Web编程语言的优势。

代码组织相关的话题
这样的观念有些抽象，没有实例的演示很难接受。在举例之前先介绍一下我对这类工程的推荐代码结构：

一级目录 二级目录 三级目录 备注
/project_name 项目源代码根目录
/Templates 网页模板目录（View）
/admin 管理控制台目录/admin下的网页模板
/Include 商业逻辑目录（Model）
/Temp 临时代码目录（可选），可供开发者进行一些试验代码的测试
/images 图片目录，网页模板采用
/css 样式单目录，网页模板采用
/scripts 客户端代码目录，网页模板采用
/admin 管理控制台目录（可选），包含所有后台管理的功能代码
/other_dir 对应与源代码根目录下的/other_dir，包含管理该类的功能代码
/other_dir 其他与相应功能相关的目录，比如与用户相关的/member目录或者与从产品相关的/product目录等等
/config.inc.php 全局配置变量，定义系统中的全局变量
/security.inc.php 安全策略控制（可选）
/error.php 错误控制返回页面（可选），也可以采用静态页面如/error.html或者其他页面名称



看完之后您是不是被唤起了一点使用Java进行Web开发的记忆？比如WEB-INF目录下的classes目录和lib目录以及web.xml都是开发中的规则--虽然支持PHP的Web服务器不可能像Java应用服务器那样自动加载这些目录下的文件，但是规定一个合适的代码组织模式还是非常有利于开发的便利和后续的维护的。（我开始考虑PHP项目的代码结构就是由Tomcat的开发手册中获得了启发。）

一个用户登录的例子
根据以上的代码目录，前文所说的MVC模式的实现可以得到更简单的解释。以最常见的用户登录功能为例，设想/project_name目录下有一个/member目录包含有关于用户的一切功能，其中包含了login.php页面接受用户登录使用的用户名称和密码，index.php页面是登录完成之后的用户主页，而/project_name目录下的error.php是登录失败后的错误显示页面。

用户通过系统的其他部分请求进入用户主页即/member/index.php页面，此时该页面判断用户情况：已登录用户则直接显示本页内容（可以采用检查session等方法）；未登录用户则需要登录（重定向到/member/login.php）；出现了未知错误（重定向到/error.php）。同时采取相应的反应。
假如用户被引导至登录页面即/member/login.php页面，该页面接受用户的登录信息（用户名称和密码），并判断是否正确登录：正确登录则再次重定向到用户主页/member/index.php；登录错误则重定向到/error.php。
假如用户被引导至错误显示页面/error.php页面（无论是从以上哪个页面前来），都会显示错误信息。



流程图示如下：





根据以上的文字描述和图示，再结合MVC模式的实现，可以非常轻松的写出这几个页面的框架代码：

先看简单的页面/error.php：

然后是/member/login.php：

最后是/member/index.php:




（注意：以上代码只是片断，而且没有考虑项目全局，只起演示作用）

关于Controller
首先可以明确的是，以上的三个页面代码就是前文所说的Controller控制/流程代码。很明显，他们的不包含特定