MVC 模式、类封装还是黑客代码 合理设计 PHP 项目-综合性网站项目

look_w

已经有一些大型网站使用 PHP 作为主要的开发语言。对于这类项目，单纯从 PHP 技术方面值得提出的话题不多，简而言之还是根据网站各部分的实际应用情况（访问强度、操作行为等）选择以上提出的两种项目设计方法或者综合使用。除此之外，根据我个人的经验，项目团队的组织和协调工作以及项目各期完成后的维护工作等等是较之单纯的技术更加关键的因素。
对于这类项目，可以提出的建议是，适当采纳一些开源软件对于快速、优质的完成项目很有好处。项目的某些部分可以直接引入开源软件项目的设计甚至是代码，不过前提是系统设计人员对这些引入的项目需要非常了解，同时需要做好这些孤立的开源项目和整个项目之间的接合（比如安全策略的考虑和全局变量的引用等）。
举例来说，根据客户要求某个综合网站需要以下的功能：

• 复杂的新闻发布；
• 需要不多管理功能的在线论坛；
• 简单的产品陈列；
• 需要用户管理。

（很明显这是一个企业网站的雏形。）
其中的 1、2 项很明显可以借用一些成熟的开源软件项目，而 3 项由于客户需求简单自主开发比较符合成本。由此看来 4 项则是整个系统中最重要的部分 -- 需要做好与 1、2 项使用的开源软件项目的用户管理集成工作（3 项由于自主开发的原因集成工作非常简单）。（某些技术积累较好的公司甚至对于以上提及的集成部分都有简单的解决方案，那么这样一个网站项目的完成所需成本非常微小。）
几个特殊的功能点另外还有一些通常项目中都会出现但是必须妥善处理的功能点：
1. 数据列表分页。
关于这个功能，互联网上的中文和英文资料都有许多。具体的技术和实施细节不需要多说，这里只需要指出的是：
A. 建议封装成某一个工具类的方法或者其他可复用的形式 -- 这样的好处不言自明，任何人都不希望系统中只要存在数据列表分页的时候都会出现一堆几乎相同的代码。
B. 如果针对一些效率要求较高的项目（例如上文提到的 " 简单网站项目 " 类型），应该直接使用 PHP 自带的针对特定数据库系统的操作函数以及与该数据库系统相关的结果集截取技术（SQL 语句），比如 MySQL 中的 'LIMIT  start,  offset' 之类；其他一些需要系统设计工整合理的项目（例如上文提到的 " 设计大量商业逻辑项目 "），如果采用了通用的数据库接口，出于兼容多种数据库系统的考虑，可以采用此接口完成结果集的筛选，以损失的效率换取系统更好的可维护性和可扩展性。也就是说，对于采用特定数据库操作函数还是第三方通用数据库接口来实现数据列表分页，需要考虑系统的性能和扩展两方面因素。
2. 错误控制。
这一点在上文之中也有提及。除了建立属于工具类的错误类之外，最好可以建立专门的错误显示页面。该页面既可以是静态的 HTML 页面（表达一些对用户的歉意和出错之后的处理指导）或者动态的 PHP 页面（可以包含具体的出错原因和地点以及其他更详细的信息，前提是在系统安全策略允许提供这些信息）。而错误类的任务就是接受正常的程序中抛出的错误，进行必要处理之后将信息一起重定向在错误显示页面上。
同时，建立出错页面对于开发阶段也有一定好处，可以弥补现有 PHP 缺少类似 try{ … }  catch{ … } 块的违例控制的缺点，将调试中的错误或者输出通过错误类抛出并显示出来。
3. 上载与下载。
对于 PHP 来说，上载的实现并不会像其他流行的 Web 开发语言那样需要第三方程序的支持，内建的机制可以非常简单的处理。不过这里提及的是一些复杂的上载功能实现。考察以下一个处理附加文件的流程：
该功能使得用户在撰写新的消息时可以附加其他文件，而且在消息没有提交之前可以随意的对已经附加的文件进行删除或者继续增加。这种需求会体现在许多办公相关的系统中，作为有经验的系统分析员应该在系统设计阶段制定完成针对该类功能的实施计划。比如在图中所示的流程中，其实是通过一个或者多个表单的互相提交完成（具体设计不再赘述，提供相关的 PHP 文件参考；另外的一个直观的例子就是多数免费邮件系统的添加附件功能，如果有兴趣可以考察一下）。
至于下载，将文件置于服务器 Web 可访问目录下、提供访问者真实文件路径是最简单的解决办法；不过一些系统中对文件的下载基于某些安全策略需要进行身份方面的判别方可予以下载，这样的方式就会带来隐患。通常采用的方式也许是将文件放置在 Web 可访问目录以外的服务器文件系统中或者存储进数据库系统 -- 都需要一个简单的程序取得文件内容并直接返回给发出请求的用户（这其中涉及到一些 HTTP 输出头的问题请注意，提供一个 PHP 文件代替具体叙述）。在系统设计时针对不同的需求可以采用相应的办法。
4. 客户会话 session 的保持
PHP 的现有版本已经内置了对 session 的支持，通常项目中都使用这样的方式；一些特殊需要的项目（比如分布系统）也许会采用复杂一些的处理方式。
在客户端，通常采用的是设置 cookie 以识别特定的客户，另一个可以应付不支持 cookie 的客户端的方法是采用 URL 重写加入足够标示特定客户的字符串。从这方面来说，采用 PHP 内置的 session 支持最为理想，因为它可以自动的进行客户端的 FALLBACK：如果客户端支持 cookie，那么就顺其自然；如果 cookie 不被支持，就采用 URL 重写方式 -- 一切都不需要开发者干预。如果采用其他 session 处理方式，或者自己编写适应需要的 session 库，需要注意的就是怎样处理客户端存储数据的问题 --cookie 还是 URL 重写还是两者兼顾。
在服务器端，简单说来只需要针对以字符串标示的每个特定客户存储相关的数据即可 -- 可以采用的方式多种多样，通常的方式是文件和数据库。 PHP 内置的 session 支持中，默认的支持方式是在系统的临时目录或者制定的目录下为每个客户建立一个文件存储其数据；当然也可以修改设置使其支持数据库的方式或者其他方式。如果自己编写 session 库，根据系统的需要选择一种合适的存储方式即可。值得指出的是，对于分布系统，如何共享服务器端的 session 信息是需要极大关注的。
另外，在设置 session 变量的时候，PHP 内置的 session 库支持对象作为变量值（实际上所有的变量值，不论是一般的变量还是数组或是对象，都在经过串行化之后被存储），也就是说，以下代码是可用的：
这一点对于上文提到的一些商用系统是有益的：首先，可以使用关于用户的对象作为一个 session 变量值存储一套信息，而不是割裂的多个 session 变量；其次，如果具有类似购物车的功能，可以以非常符合整个系统设计的方式（即前文所述商用系统的设计方式，强调类封装）将该购物车对象放入 session 中。
5. ……其他和特定项目有关的功能点……
如果能在系统设计阶段就预见并解决这些功能点固然很好，即使有少量未发现的功能点遗留到了编码阶段也并不可怕 -- 通常这样的遗漏并不会影响整个系统的架构，只是需要返回设计阶段加入相应的内容和文档即可。毕竟对于相关项目经验不太丰富的系统分析员来说，做到设计阶段对这类功能点了然于胸是不太现实的。
关于其他对于 PHP 的争论从前很多，不过自从 Java 在 Web 方面的优势越来越进入人们的视野之后，这样的争论倒偃旗息鼓了 -- 看来大家都达成了共识 --PHP 对于严谨的商用系统还是无能为力。不过基于此就一味否定 PHP 在商用系统中的应用也不大客观，毕竟 PHP 还具有低成本的优势（这里的成本包括开发成本、使用成本和维护成本）。本文的目的除了讲述一些 PHP 系统设计的方法之外，也希望吸引一些开发者或者企业采用 PHP 构建合适的商用系统。