MVC 模式 类封装还是黑客代码.docVIP

MVC 模式 类封装还是黑客代码 合理设计 PHP 项目 简介：?编码对于合格的 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 之类）而根本不需要被服务器端的 ? … ? 干扰。程序设计人员则被分为两部分：其中比较容易把握的是商业逻辑开发人员，他们的任务是根据系统分析员给定的模块（准确说是类方法）完成之，在他们手中 的