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

面临难题
编码对于合格的PHP程序员来说并不是什么难事（也许只是花费时间长短的问题），因此系统分析和设计这一阶段就显得尤为重要。对于一个担任PHP项目的系统分析员来说，面临着两个难题：

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

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

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

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

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

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

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

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

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

看完之后您是不是被唤起了一点使用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是登录失败后的错误显示页面。

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

流程图示如下：

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

1. 先看简单的页面/error.php：
   
2. 然后是/member/login.php：
   
3. 最后是/member/index.php:
    

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

关于Controller
首先可以明确的是，以上的三个页面代码就是前文所说的Controller控制/流程代码。很明显，他们的不包含特定的操作，也没有一行网页代码，有的只是与前面流程图一致的流程控制代码（放眼望去，这些页面的共同特点是充满了引用网页模板并输出、取得对象并执行其某个方法或者重定向）。

再选择其中的一个页面/member/login.php详细的解释。整个页面通过判断是否提交表单分为两个部分：显示登录表单供用户填写和处理登录信息。作为前者直接引用一个处于网页模板目录/Templates下对应该页面的member_login.dwt并在解析后输出；作为后者先取得一个Member对象（该对象出于商业逻辑目录/Include下的Member.inc.php中），然后获得登录判断的结果后进行重定向。在这个控制页面的代码中，member_login.dwt作为View视图/界面出现，类Member作为Model模型/逻辑出现，而页面代码本身就Controller控制/流程。下面就是加入标示的/member/login.php框架代码：

（关于模板类以及在MVC模式中的应用，可以参考本站另一篇文章《在PHP中选择合适的模板》）

关于Model
既然谈到了Model，下面就是另一个重要的话题：类封装在PHP项目中的应用。

请注意用词"类封装"--这和"面向对象"或者其他什么"采用对象设计"的方法有着本质的不同。"类封装"只是讲述了将商业逻辑采用类方法的方式封装成各个不同的类，因而这里的"类"并不是因此采用了面向对象设计出现的"类"--准确的说，这里的"类"其实是对一系列相关功能模块进行合并的结果。

为什么不直接采用面向对象的方式而是采用这种看起来不伦不类的办法去设计系统呢？PHP不是具有面向对象特性吗？不错，PHP具有这样的特性，但是非常不完全（可以参考本站另一篇文章《从Zend Engine 2.0的设计蓝图（草稿）看PHP的将来》）。举例来说，PHP是没有接口这一概念和实现方法的，同时也就没有什么多重继承、方法重载之类的典型面向对象特征。如果非要采用面向对象的设计方法，也许在概要设计阶段可以非常轻松，但是详细设计阶段就会比较苦闷，而如果还有幸坚持到编码阶段简直就是苦不堪言了。另一方面，如果不在系统中引入类的概念，而是采用函数来实现模块功能，那么可以想象在一个采用这样"纯粹"的中大型系统中会有多少的函数，由此带来的麻烦非常明显。

还是回到PHP语言本身。虽然PHP提供不了什么实际的面向对象支持，但是还是提供了对类以及其中的属性和方法的定义。那么自然而然可以想到的是采用类的方法封装相关函数模块，既可以借鉴一些对象设计的优点，又可以避免完全采用函数模块的一些缺点。

（一些采用函数模块的系统会采用这样一种方式：将相关的函数编写在相同的文件中，这样在引用时可以引入单独的文件。比如Member.func.php这个文件中包含了所有与用户相关的操作，在处理用户登录时可以先require这个文件，然后调用诸如member_login()这样的函数。但是这样的方式仅仅解决了系统中众多函数的代码组织问题，没有解决名字冲突的问题。下面的举例中就会看到。）

比如上文的用户登录实例中，如果采用函数模块的方法，代码也许是这样：

而采用类封装的方法，可能就是这样：

也许您会觉得代码并没有什么区别（甚至看起来采用函数模块的代码由于不需要取得新的对象而显得更简洁一些），而真正的不同是发生在include的文件里面。采用函数模块的方法将相关的函数集合在一个文件中加以组织（有些系统还不能做到这一点，那么就会造成异常混乱的局面），而采用类封装的方法在每一个文件中声明一个和文件名相同的类（比如在Member.inc.php声明一个Member的类，这一点和Java的规定相似）；而在使用时，都需要先进行include（如果采用函数模块又没有进行很好的组织，也许有些人就会很"简便"的将所有函数include进每一个页面--PHP可不是Java那样编译执行，光是解析这些函数就会花费一段时间），但是关键就在于采用类封装的方法可以清楚的指明调用的位置--某个类（Member）的某个方法（login）：从避免名字冲突的角度来说这一点是非常成功的；而对于代码检查和维护而言，方便程度更是不言而喻。设想一个页面需要完成若干功能，因而需要include数个文件：采用函数模块的方法不能够轻易的从函数调用中找到函数本身所在的文件（如果函数名称或者include文件名称没有什么统一规则，那么这个工作就非常艰巨了），而采用类封装的办法可以根据类名称和类文件名称准确定位类方法代码的位置。（也许您会认为这样一个小小的好处不足挂齿，但是经历一个维护工程之后也许就不会再有什么异议。）

以上是采用类封装方法的原因，决定采用这种方法设计系统只是第一步；完成整个系统的设计还有很多可以借鉴的经验。

1. 部分设计可以借鉴面向对象的思路。虽然PHP中没有接口和抽象类的定义，继承机制也非常不完全，但至少具备了基本的类定义和简单的继承关系。类似"公司－雇员"、"卖家－商品－买家"这类显而易见的关系可以很容易在系统中通过类和类关系定义。既然PHP可以做到这一点，就按照实际的逻辑关系去定义即可。
2. 经常会在系统中出现的另一个情况是关于个体和列表的关系--这样说也许难以理解，想象一个BBS系统中的帖子列表和每个帖子之间，就是这样的关系。根据设计经验，这样的关系大量存在于PHP或者其他Web系统中。对于这类关系，我个人建议可以采用以下Item和Item_List的类封装方式：
   • Item类定义：Item.inc.php的代码
   • Item_List类定义：Item_List.inc.php的代码
3. 由于PHP对于类的成员变量和方法并没有语法上的访问限制（均为公开），因此会带来对象使用方面的某些混乱。基于此，建议在开发团队的代码规范中加以规定，从代码应用的级别上控制这一情况：
   首先，可以通过对成员变量和方法的注释来说明其属性，由此使用该对象的其他开发人员可以了解自己的使用方法是否触犯了规定的访问限制。（如果采用phpdoc等自动文档生成的工具，开发人员甚至可以在不翻阅类源码的情况下通过浏览类文档正确使用它。）
   其次，对于成员变量访问限制的考虑，可以将一些主要的、经常需要被访问或更改的变量（在注释中）声明为公开。这样的作法可以省却大量get()和set()方法的代码--虽然在其他的面向对象语言中这一点被认为非常丑陋，但是记住PHP不是Java，只要这样的用法合理，就应该大胆使用。
4. 从上面的示例代码中您也许已经注意到了注释的比重--虽然大家都了解注释的重要性，但是仍然有必要提出。这个示例中采用了Javadoc的样式，利用现有工具也可以很容易的直接生成文档（当然您和您的开发团队也可以定义自己的合适注释样式和文档生成工具）。对于系统分析员来说，您在设计阶段完成之后交付给您的开发伙伴的代码部分很可能就是这些注释占绝大部分的框架代码；你们之间交流的工具除了那些没完没了的图表之外就是这些程序员最熟悉的代码和注释了。

在PHP系统中进行类的设计虽然不像构建面向对象系统那样需要各种合理的模式介入（也没有这样的"本钱"为之），但还是需要一番思量的。逻辑上的合理性和操作上的可行性都是检验的标准。

（说到类设计，又想到了适合PHP开发的IDE问题。据我所知比较专业一些有Zend出品的Zend IDE；另外还有作为JBuilder的Open Tools出现的借助JBuilder的PHP开发工具；不过最常用的还是PHPEd或者UltraEdit之类的编辑器。如果现有的编辑器可以非常聪明的支持PHP的类设计和代码实现就非常理想了。）

关于View
最后说到的是View方面，虽然这部分内容与网页设计人员联系比较紧密，不过PHP项目（以及其他Web项目）的系统分析员也必须关注这一话题。可以看出MVC模式的应用使得网页开发人员和程序设计人员的各自工作成果不会像以前那样互相影响，自然可以提高各自的工作效率（相互关系也许会比以前更加融洽一些）。但是对于系统分析员来说，将用户界面分离为各个独立的网页模板需要进行许多分析工作。

首先是确定整个系统的流程，这一点在系统设计的初期就应该做到。而对于View视图/界面和Controller控制/流程来说，所有需要的页面都是围绕此流程产生。不过通常此时能够在流程图上看到的也许只是相关的参数在各个页面之间传递，却不能了解各个页面展示的内容--这就是下一步分析用户界面需要进行的工作。

在分析用户界面的工作中，第一步可以确定各个页面核心、对于完成流程必不可少的用户界面元素（表单和表单域、链接等）；第二步是确定页面中需要出现的导航内容；最后还需要依据流程复核。还是以上文的用户登录为例。对于/member/login.php这个关键的页面，第一步可以确定的是在用户提交之前应该显示一个表单，表单包含两个文本框供用户输入用户名称和密码；而提交之后根据流程在本页面中不需要有用户界面，取而代之的是利用Controller控制/流程这一逻辑层进行重定向。而第二步需要制定该页面中（准确说是在显示登录表单时）需要提供的导航链接，在这里可以加上到系统的主页或者其他非注册用户页的起点的链接（方便用户临时决定取消登录）以及一个注销现有用户的链接（针对已登录用户）。之后进行复核，此时也许会发现这一设计似乎没有考虑到在登录前更好的区别是管理员登录还是普通用户登录，那么就可以在表单中增加一个隐藏域表示选择登录的用户是准备以管理员还是普通用户的身份进行登录。

确定完用户界面的元素，并不意味着可以将这些分析结果交付网页设计人员进行制作了；还有最关键的一步没有实施--为分析完成的各个页面制定模板所需的变量名称。对于以上的用户登录实例，如果系统有识别曾经登录用户的功能（依据之前访问时在客户端设置的相关cookie值）并且把这个用户名称显示在登录表单的用户名称一栏，此时就需要在member_login.dwt设计中说明该表单域将被赋值为一个模板变量（比如{USERNAME}）。这一步骤完成之后就可以交付网页设计人员进行制作了。

需要指出的是，在编码阶段很可能局部的一些系统设计需要进行修改，这其中也许就包括对网页模板的修改，需要仔细处理。

对于代码组织的补充说明
还有几个文件和目录没有在上文提及：

1. config.inc.php -- 如果您熟悉phpMyAdmin或者其他phpWizard.net释出的项目，就应该非常清楚这个文件的作用：定义本项目范围内的全局变量（在每个页面中被include）。我个人认为这是一个非常良好的设计，因此也提倡在项目中应用。另外，为了保证与项目中其他的变量冲突，建议在该文件中定义一个多重数组，而各种全局变量都以该数组的某一个值出现。这样方便团队中的其他开发者只需要避免一个变量名的使用，而不是避免所有config.inc.php中出现的变量名。使用这个文件的另一个好处是由于将关键的变量（比如与服务器环境相关的变量）集中定义，可以方便的安装和移植整个项目。
2. security.inc.php -- 顾名思义这个文件控制并实施整个系统的安全策略。关于安全问题，可以想到的是两种控制方案：在每个控制流程页面顶端针对本页面加以控制以及采用一个控制文件整个控制并被加入每个控制流程页面。我个人提倡采用后一种方式，原因也很简单：定义简单而且维护方便。虽然相比每个页面单独定义，也许会损失一点点效率（一些不需要安全控制的页面也需要include该文件并进行判别），但是获得的是对系统安全的整体控制以及代码维护的便利（损失一个if…else…的判别换取这样的结果还是很值得的）。
3. /Temp -- 很明显存在于这个目录下的都是一个临时文件，并且这个目录其实并不会出现在项目正式发行的版本中。如果开发时对一些函数的使用不甚明了或者试验一段没有相关经验的代码，都可以在此目录下建立文件；因为该目录就位于项目代码之中，可以非常便利的取得项目运行的上下文环境，大大降低了试验代码的成本。
4. /admin -- 通常对系统的后台管理内容应该放置在一个独立的目录中，我个人比较喜欢admin这个简写词（当然也有一些情况系统分析员认为不应该设置一个容易猜测的管理目录名称以增加一重对系统安全的保护）。
5. /css和/scripts -- 都是与网页设计也就是View视图/界面有关的文件存放处，分别是样式单和客户端脚本。这样做的好处在任何一本讲述网站规划的书籍中都会有所提及。

方案二：简单网站项目
系统性能是这类项目追求的首要目标，而与此同时系统的维护和扩展几乎可以不用多加考虑。（也许这句话听起来有些绝对，但是根据客户的需求和项目的性质判断，尽最大可能以最短时间满足客户的需求并使得系统高效运转就是项目成功的最好检验标准。）因此，也许这类项目就是PHP黑客的天堂（曾经我也是一个过分追求PHP使用效率的人）。由于这类项目的特殊性，这里讨论的范围不仅仅局限与系统设计而是从组建项目小组开始直到交付项目的过程。

首先需要关注的是参与项目的人选（虽然也许这是项目经理的职责，但是最熟悉PHP项目特点的系统分析员应该参与）。在PHP开发人员方面，至少应该选择对PHP各种函数较为熟悉的开发者（这类项目不适合作为现实项目以培训参与的开发新人），如果公司中还有能够在源码级别理解PHP的人员就更加理想（不过通常对于一般的PHP开发公司是不可能的）。而在网页设计人员方面，最好可以选择一些略通客户端（比如JavaScript）以及服务器端（最好是PHP）脚本的人员；因为这类项目的一大特点即是单个网页代码量较大且夹杂网页代码（通常是HTML）、客户端脚本（比如JavaScript）和服务器端脚本（比如PHP），加入了解各种脚本语言的网页设计人员的目的不是为了增加团队的PHP开发力量，而是避免在修改网页时影响程序设计人员的工作。

其次就是面向过程，准确说是面向页面的系统设计。相对第一类项目，客户的需求在该类项目中表现得非常清晰，而且一般长期进行Web开发的公司对于这类网站项目也应该有一定的设计经验积累。设计中需要围绕整个系统的流程，包括每个页面的输入参数和输出内容（包括网页中出现的除导航链接之外的功能性链接），以求完全满足客户的需求；另一关键在于确定系统安全策略，在这类项目中主要是用户等级的确定和页面的访问权限，并给出实现的方式。不过还需要指出的是，这类项目中由编码阶段返回设计阶段的情况并不少见，对于局部设计（比如页面传入参数或者输出链接）的更改应该加以及时控制。

最后是针对代码和数据库的优化。在这类项目中需要适当鼓励开发人员的黑客态度。推荐的办法是系统分析员给出每个页面的伪代码（框架代码），而局部的实现则由各个程序开发人员和网页设计人员进行。

对于PHP代码方面，通常可以从如下几方面考虑：

1. 算法的选择和功能实现的方式：模块级别的优化，可以由几名开发人员共同讨论解决；
2. 函数的使用：代码级别的优化，需要开发人员对各类函数有清楚的认识，至少养成多多参考函数手册的*惯；
3. 数据库的查询和更改即SQL语句的使用：如果公司中有相关数据库系统的管理人员，可以就一些优化问题征询他们的建议；
4. 其他应该避免的问题：比如拷贝代码、等不良代码情况。

而根据我的经验，通常会在这类项目中撰写的黑客代码如下：

1. 循环语句的使用特别是在查找时的应用：此时注意while和for的区别（想必大家在大学课堂中都做过这类的程序），这也是良好的编程*惯；
2. SQL语句的优化：首先是尽量避免多余的数据库交互，这是提高效率非常重要的一点；其次是不要害怕长达几行的语句而宁愿使用所谓简单的语句；再次是认真考虑查询语句返回的字段，减少不必要的数据。
3. 表单提交值的获取，比如复选框和文本域。精巧的表单域名称设计可以减少一定的代码量，而处理提交值时也需要注意处理的方式。

黑客代码在这类项目中值得鼓励，不过最好在每段代码旁附上尽可能详细的注释。

由于该类项目的特殊性，完成项目的关键不仅仅在于系统设计阶段，因此给出项目开始、系统设计、编码以及测试、交付这一过程的简单描述：

1. 挑选合适人员组成项目小组，可以考虑销售人员和客户代表的加入。
2. 系统分析员可以简单的从客户的需求以及以往项目经验的结合中总结出系统所需的每个网页并对其功能作出描述，同时确定初步的安全策略。这一步骤中可以加入销售人员和客户代表的加入。（此时网页设计人员正在准备提供给客户的一系列网站形象页面。）
3. 详细设计中需要为每个页面确定位置和名称，更加关键的是确定输入参数和输出内容以及不同级别用户对于网页的确切访问权限。同时进行数据库设计。该阶段完成后至少应该提供系统的流程图（包括访问权限标识）以及数据库设计资料。
4. 网页设计人员和程序开发人员拿到相关资料各自进行工作。对于前者，根据客户认可的一套形象设计每个页面；对于后者，开始进行"兴奋的"（因为此时要求的是高效简介的代码--黑客代码）编码工作。此阶段工作中遇到的困难均需要反馈到系统分析员处，可能返回以上的第3步甚至第2步进行设计修改。
5. 程序编写和网页设计结束后需要有一段整合的时间，也是程序开发人