理解PHP中的MVC编程之MVC框架简介.doc

什么是 MVC？】MVC 是一个可以让你把“三个局部〔即 MVC 的全称，Model、View、Control ler〕”谐调地组成一个简单应用程序的概念一辆汽车就是一个在现实生活中格外好的 MVC 例子我们看车都看两个 View〔显示〕局部：内部和外部而这两个都离不开一个 Controller〔把握者〕：司机刹车系统、方向盘和其他操控系统代表了 Model〔模型〕：他们从司机〔Controller〕那里取得把握方法然后应用到内部和外观〔View〕网络上的 MVC】MVC 框架所涵盖的概念相当简洁并且极度机敏根本的概念就是，你有一个单独的把握器〔如index.php〕用来把握全部建立在参数恳求根底上的框架内应用程序这个把握器通常包含了〔最小程度上〕一个定义模型的参数、一个大事和一个 GET 参数这样把握器就能确认全部的恳求然后运行相应的大事打个比方来说，一个像这样/index.php?module=foo&event=bar 的恳求很有可能就是用来载入一个名叫 foo 的类，然后运行 foo::bar[就是其中的 bar函数]这样做的好处有：一个对应全部应用程序的接口同时维护一个应用程序内很多的代码格外麻烦，由于每一段代码都有自己的相对路径、数据库链接、验证等等。

而这样做就免除你在这方面的苦恼，允许你合并并重复使用代码【为什么要创立作者自己的 MVC 框架？】迄今为止，我没有见到过太多用 PHP 写的 MVC 框架事实上我仅仅知道一个－Solar，是完全用 PHP5 写的另外一个是 Cake，一个试图成为 PHP 的 RoR〔R uby on Rails－一个 Ruby 语言开源网络框架〕我自己对这两个框架都有一些不满足的地方：它们都没有利用到 PEAR，Smarty 等所包含的现有代码；现在的Cake 还比较紊乱；最终，Solar 是一个绝大局部由一个人写的作品〔我无意说其作者 Paul 不是一个好人或者好程序员〕这些问题可能并不会让你否认它们， 而且很有可能你根本不关心这些问题但是正由于如此，我请各位尽可能地打量它们老方式】假设回到 2022 看自己写的代码，作者有可能找到一个叫 template.txt 的文件，它看起来像这样： 转载请注明出处＜?phprequire_once(”config.php”); // Other requires, DB info, etc.$APP_DB = ”mydb”;$APP_REQUIRE_LOGIN = false; // Set to true if script requires login$APP_TEMPLATE_FILE = ”foo.php”; // Smarty template$APP_TITLE = ”My Application”;if ($APP_REQUIRE_LOGIN == true) {if (!isset($_SESSION[”userID”])) { header(“Location: /path/to/login.php“); exit;}}$db = DB::connect(”mysql://”.$DB_USER.”:”.$DB_PASS.”@localhost/”.$A PP_DB);if (!PEAR::isError($db)) {$db-＞setFetchMode(DB_FETCHMODE_ASSOC);} else {die($db-＞getMessage);}// Put your logic here// Output the templateinclude_once(APP_TEMPLATE_PATH.”/header.php”); include_once(APP_TEMPLATE_PATH.”/”.$APP_TEMPLATE_FILE); include_once(APP_TEMPLATE_PATH.”/footer.php”);?＞天哪，只是看这些代码都会让我有退缩的欲望。

这段代码的概念就是确保每一个应用程序都能适用于这个处理方法，比方我可以简洁地将 template.txt 拷进 myapp.php，转变一些变量，瞧，它就能运行起来了尽管如此，这个组织严密的处理方法存在一些严峻的缺点：假设我的老板想让作者用 myapp.php 在一些状况下输出 PDF、一些状况下输出 HTML、一些状况下〔直接提交的 XML 恳求〕SOAP，我该怎么办？假设这个应用程序需要 IMAP 或 LDAP 验证，我该怎么办？ 我该如何处理各种不同的代码〔包括编辑、升级和删除〕？我该如何处理多级验证〔治理员 vs. 非治理员〕？ 我该如何启用输出缓存？ 转载请注明出处【方式】将全部东西都扔进这个 MVC 框架，你会觉察生活是如此简洁请比照以下代码：＜?phpclass myapp extends FR_Auth_User{public function construct{parent:: construct;}public function default{// Do something here}public function delete{ }public function destruct{parent:: destruct;}}?＞留意这段代码明显不是用来链接到一个数据库、推断一个用户是否已经登陆、或者输出任何其他信息。

把握器把握了全部的一切假设我想验证 LDAP，我可以建立 FR_Auth_LDAP把握器可以识别某些输出方法〔比方$_GET[”output”]〕并可以随时转换成 PDF 或者 SOAP大事处理 del ete，只负责删除，其他的它都不管由于这个模块拥有一个 FR_User 类的实例， 它可以简洁地推断一个用户是否已经登陆等等Smarty，作为模板引擎把握缓存是理所固然的，但是把握器同样可以把握一局部缓存从前面讲的老方式到 MVC 方式对于很多人来讲可能是一个全、生疏的概念， 但是一旦你转换到了这样一个概念，那么要转回去将是件相当困难的事情建立底层】我是一个 PEAR 尤其是 PEAR_Error 类的爱好者PHP5 引入了一个的内建类“Exception” 取代了 PEAR_Error但是 PEAR_Error 拥有一些比 Exceptio n 还要有用的特性所以，在此系列文章中的MVC 框架实例将用到它来做错误处理无论如何，我还是要用到 Exception 获得从构造器中的错误，由于它们本身不能传回错误设计这些根底类的目的有如下几点： 利用 PEAR 快速添加功能到根底类建立小巧、可反复有用的抽象类以便让使用者在此框架中快速开发出应用程序用 phpDocumentor 给全部的根底类生成文档类的层次看起来会像这样：-FR_Object 将会供给根底的功能以供其他全部对象使用〔包括 logging，一般的 setFrom，toArray〕-FR_Object_DB 是一个小层面，给子类供给数据库链接等功能-FR_Module 是全部应用〔又称模块、模型等等〕的底层类-FR_Auth 是全部验证机制的底层类·FR_Auth_User 是一个验证类，用来验证全部需要验证用户是否登陆的模块·FR_Auth_No 是全部不需要验证的模块的“假验证类”-FR_Presenter 是全部用来处理载入和显示应用的底层类-FR_Presenter_Smarty 是包含了载入不同驱动器力量的显示层。

Smarty 是一个格外好的模板类，它拥有内建的缓存机制以及一个活泼的开发团体〔译者注： 这清楚就是打广告嘛～〕·FR_Presenter_debug 是调试局部的显示层依靠它，开发者能够调试应用程序并给他们除错·FR_Presenter_rest 是一个可以让开发者能够以 XML 方式输出应用程序的 REST 显示层从以上的根底类构造上，你应当可以看到这个 MVC 框架的不同局部FR_Mo dule 供给全部模块所需要的东西，而FR_Presenter 则供给不同的显示方法在此系列文章中的下一篇中，我将创立把握器将这上面全部的根底类结合在一块代码标准】在你正式编写代码之前，应当坐下来跟你的合伙人〔或者你自己〕好好争辩〔或思考〕一下代码标准MVC 编程的整体思想围围着两点：代码的可再利用性〔削减偶合〕和代码的标准化我推举至少应当考虑到如下几点：首先要考虑的是变量命名和缩写标准不要由于这个跟你的合作伙伴大吵一通，但是一旦定下来的标准，就要自始至终地遵从，尤其是写底层代码〔根底类〕 的时候定制一个标准前缀，用在全部的函数、类和全局变量上不走运的是，PHP 不支持“namespace〔命名空间〕”。

所以要想避开混淆变量名和发生的冲突， 用一个前缀是个明智的做法我在整篇文章中将使用“FR_”作为这样的前缀编写底层】文件层次规划很重要根本的层次规划很简洁且在肯定程度上是严格定义的：/ config.php index.php includes/ Auth.php Auth/ No.php User.php Module.php Object.php Object/ DB.phpPresenter.phpPresenter/ common.php debug.php smarty.php Smarty/ modules/ example/ config.php example.php tpl/ example.tpl tpl/ default/ cache/ config/templates/ templates_c/你可能会想这样的文件层次确定代表了很多的代码！没错，但是你能够完成它的在整个系列完毕后，你会觉察你的编程将会变得更简洁并且开发速度会得到很大的提升在文件层次里面，全部的根底类都在 includes 文件夹内每一个功能模块， 都用一个配置文件，至少一个模块文件和一个模板文件。

全部的模块包含在mod ules 文件夹内我已经习惯了将模板文件放在单独的外部文件夹内，也就是 tp l 文件夹config.php－中枢配置文件，包含全部的全局配置变量index.php－把握器，在接下来的一篇文章中会具体表达 object.php－全部根底类的底层类，供给绝大局部类需要的功能FR_Object_DB 继承这个类并供给数据库链接构造的根本概念就是，让全部的子类都继承一个中枢类以便它们都共享一些共同的特性你完全可以把链接数据库的功能放进FR_Object，但是并不是全部类都需要这个功能的，所以 FR_Object_DB 就有了存在的理由，作者会稍后做出争辩它＜?phprequire_once(”Log.php”);/*** FR_Object** The base object class for most of the classes that we use in our framework.* Provides basic logging and set/get functionality.** @author Joe Stu。