在PHP中使用灵巧的体系结构_php基础_脚本之家

很早就想写这篇文章了,但一直没有时间完成它。不是说我来告诉大家如何做,我更希望本文只是做为一个引子,与大家来讨论关于如何建立一个有效地、灵活的网络应用程序。
经过了2-3年的网络应用程序开发工作,我的开发经验变得更加生动了,回过头来看我以前为Geocrawler写的代码,简直不敢相信这是我的。由于GPL的原因,在PHPBuilder中的源码也是良莠不齐的。
最近我做为一个有经验的PHP开发者,一直在帮着写SourceForge,我想这显示出了最终结果的一个范围。好的代码应被分成了多个部分,合适的库及函数调用,清楚的数据库结构,站点的每一个部分与其它部分都是相对独立的。
但是,这仍不是最好的。如果我可以重做,我将更多的关注于HTML层与数据层的分离,通过对象及清楚的函数库实现这一点。
优美的图形
我知道经理们喜欢用优美的图形及图表来描述它们,这将给我们留下最好的印象。用这种隐藏在一个结构后的想法,你可以把你的逻辑与外观分离,这意味着任何一个复杂的程序都可以用”API/Data
Access Layer”来表述。
与其你把安全检测、更新的句子等放在HTML层中,不如把它们整体地放在你的API层里。而这个HTML层只含有简单的函数调用和返回的数组、对象或自定的其它什么,以及一些数据库的检索结果的集合等。
如果你这样做了,顶层将是非常的瘦小,你可以方便地创建及维护它。
如下的例子中,这个HTML接口中只有一些API层中的函数的直接调用,一些HTML工具库,和一些从数据库抽象层中调用的数据库操作方法。基础
灵活的PHP程序结构最基本的方面有以下几点: 数据库无关性 界面无关性
可移植性 面向对象或至少应由函数库组成 还有其它的?
当然还有一些其它的东西,但我认为那都是太大了,或许你自己能指出它们。
让我们详细地谈谈它们每一条吧。 1、数据库无关性
你从不知道你的站点将会在哪里运行,当然在你创建它时,你希望它变和得很大并且有很高的流量。所以你不想把你自己约束在
MS Access
上面或者其它什么轻便的数据库系统。虽然你不能立刻地插入各种不同的数据库系统,但是你有可能很方便地在它们中间切换。你有一些不同的选择可以把你的数据库调用抽象出来。在PHP中一个奇特的方法是你不得不为每个不同的数据库系统写出不同的代码,因为在PHP中对每一种不同的数据库的访问函数是不同的。为了避开这点,你可以使用一个抽象地数据库访问层,就象PHPLib、下一个版本的PEAR、及我们在SourceForge中描述的那样。
2、界面无关性
一个应用程序是它的技术更重要还是它所运行的站点更重要?我们并不能真正地知道。我从来不相信这一点--HTML是一个标准。特别是对于一个网络应用程序而言,界面发生了改动,意味着我们不得不总是重写。但是如果你的应用程序是很大很复杂的,你就要为你的数据库建立一些其它的接口了,只要你不想在你的站点程序中到处copy&paste你的访问检查等代码。这也意味着,如果你正确地设计了你的应用程序,你可以很容易地改写你的站点让它适应WAP,只要简单地写一个小的WAP界面,并让它调用你的数据库访问对象而已。但若你没有很好地设计你的程序,你把你的HTML版改成WAP版是一个复杂的工程。
我把这个想法也带入了SourceForge中,我们有一个巨大的用户群,为我们发送/接收bugs、任务等。首先,我们指出所有的这些将通过我们的web页面接口,然后,由于Eric
Raymond 和其他人给的压力,我们决定用XML来做数据库的外部接口。
幸运的是我们曾在四月已把程序的核心逻辑代码与它的界面分离了。我将试着表达我们是如何做的,希望对你的工作有所帮助。
这个SourceForge的bugs跟踪器和其它的一些工具被分成两个库-这个HTML库和数据访问库。这个数据访问库检查输入的值的正确性,处理安全校验,并且当成功/失败时返回TRUE
或 FALSE。
由于简化的原因,这个例子并没有基于一个完善的对象模式,那样我还要解释这个基类和它的一些衍生类等等,我想这个例子将给你一个最普通的想法。HTML
库的例子 //connect to database require (“database.php”); //common utils
like header/footer HTML require (“html.php”); //data access library
require (“bug_data.php”); echo site_header(“Page Title”); echo ”
Updating A Bug”; if (bug_data_update($field1,$field2,$field3)) { echo
” Update Failed!”; } else { echo ” Updated Bug Successfully”; //echo the
global error string echo $feedback; } echo site_footer(); ? Data
访问库的例子 3、可移植性
毫无疑问,你不想让你的代码只能用于一个固定的站点,将来我们可能改变色彩的选择、元素的名称、字体或其它一些什么,这样应设置一个config文件,它被多个页面所包含。更好的观点是你的站点被模块化,你不需要copy&paste任何一个HTML文件,我倾向于把这些放入一个函数,在任何需要的地方调用它们。
同样的方法可用于数据库的密码、数据库连接字串等,这些可以放入一个数据库处理的抽象层中。
4、面向对象/函数化
我们不是用COBOL开发,所以这意味着我们可以把进程分成多个函数的调用。每个调用都是一个自动的行为,有时仅仅是调用一小段其它的函数并返回这个结果。
一个好的例子是在每一个页面校验用户是否登录,你可以用cookie或查询数据库来完成这个功能,但一旦你想改变你的验证系统,你不得不改动每一个页面,其实你应该可以通过改动函数库里一个普通的函数就完成这个变动的。任何时候,你写一段代码,如果它将会被用于多于一个地方,你就要考虑把它放入一个库里了。
其它还有什么?
显然还有很多我没有谈到的事,告诉我你的想法,我将在下一篇文章中来讨论它们。特别地是,如果你写了一个大型的、复杂的应用程序,我想听听你是如何规划它的及你重做时不什么不同的想法。

很久以前我就想写这篇文章了,但是一直都没有时间。这里并不是想要告诉你怎样做,我希望它可以投石问路,和大家讨论一下如何开发一个好的、扩展性佳的web应用。
我从事开发已经有2-3年了,回望刚开始做的程序,真有点不相信是自己写的,现在我的web开发技巧已经得到了很大的提高,例如sourceForge(
不过这个站点也不是完美的。如果我必需再写一遍,我将会通过对象或者函数库的方式,让HTML层与数据库层更明显地区分开来。
我发现不少的管理者都喜欢用图表的形式来表示自己的想法,这里我也提供一个。这种体系的意念是要将你的逻辑从表层中独立开来,这意味着任何复杂的东西都会下放到“API/数据访问层”。
对于安全检查、更新等代码,你最好不要放在HTML层中,你应该将这些理论上的代码放到API层。HTML层将只会进行简单的函数调用,并且返回数组、对象或者我最喜爱的数据库结果集。
在这个图中,HTML接口或者直接调用API层,或者调用一个HTML工具库,而那些库通过一个数据库抽象层可调用数据库。
基本的要点 对于一个灵巧的体系来说,有以下基本的要点: 1。数据库独立
2。表示层独立 3。便于修改 4。面向对象或者至少拆成函数库调用
这些都是我想到的,除了以上提到的外,肯定还有其它的要点,你可以在论坛中提出来。
以下就让我们详细地讨论一下以上各点: 1。数据库独立
你在设计的时候,或许不会知道自己的站点的负担究竟有多大,应此你应该记住一点,不能绑定在轻量级的数据库上,例如MS
Access或者其它。因此你应该考虑到扩展性,如果更换数据库的话,你不用做太大的改动,甚至不用做什么改动,这是最理想的。
使用PHP时,对于各种数据库的函数调用都是不同的,你需要针对使用的数据库进行不同的编码。为了改变这种情况,你可以使用一个数据库抽象层,例如类似PHPLib或者其它人开发的库。
2。表示层独立
假如你要开发一个真正巨大、复杂的应用,你就必需开始考虑数据库的接口问题,这样你可以少做很多复制和粘贴的工作。例如你需要让你的站点具有WAP功能,以便移动电话的用户可以访问到它。如果你的应用设计得好的话,你只需要写一个轻便的WAP表示层调用所有你的数据库访问对象就行了,但是,如果你的应用体系设计得不好,你就可能需要重新写一个,这样你就需要同时维护一个HTML版本和一个WAP版本。
例如在开发SourceForge站点时,我们有大量的用户要提交他们的bug和任务等。开始时我们将它设计为全部通过web接口进行。后来在某些人的压力下,我们决定使用XML接口展现数据库。我们成功地将站点的核心逻辑由表示层中分离出来。现在的SourceForge上的bug跟踪和其它工具都使用两个不同的库–HTML库类和数据库类。数据类负责检测输入的值是否有效,并且处理安全检测,而表示层只是根据成功/失败返回true或者false。
为了简化,在我必须解释基类和其它对象如何扩展这些基类时,这个例子将不会基于一个完美的对象模型。不过我想这个例子能帮你建立一些概念。
HTML类的例子 //连接数据库 require (“database.php”);
//通常使用的HTML头部/页脚 require ; //数据访问库类 require
(“bug_data.php”); echo site_header(“Page Title”); echo ” Updating A
Bug “; if (bug_data_update($field1,$field2,$field3)) { echo ” Update
Failed! “; } else { echo ” Updated Bug Successfully “;
//显示全局错误字符串 echo $feedback; } echo site_footer(); ?>
Example Data Access Lib /** * 控制更新数据库中的一个bug *
进行数据有效性和安全的检查,并且在成功时返回true, * 失败时返回false *
* */ function bug_data_update ($field1,$field2,$field3) {
//全局字符串,返回错误 global $feedback; //$field1 and $field2 are
required if { $feedback=”Field 1 And Field 2 Are Required”; return
false; } //确认用户有权更新 if { $feedback=”You Must Be An Admin To
Update a Bug”; return false; } //现在可以更新该bug
$result=db_query(“UPDATE bug “. “SET field2=’$field2′,”.
“field3=’$field3′ “. “WHERE id=’$field1′”);
//现在检查你的语句是否执行成功 if { //update failed return false; } else
{ return true; } } ?> 3。便于修改
你当然不会在整个应用中都使用绝对的URL,不过我还要求更进一步,颜色的选择、元素的名字、字体和其它可能的选项最好也不是绝对的,它们应该在一个配置文件中设置,并且在每一页中将该文件包含进来。站点的风格也应该独立开来–这样你就无需在每个页面都进行拷贝粘贴的工作,我通常都将这些HTML放在一个函数中,然后就可以在需要时调用。
对于数据库密码、数据库连接等,同样也放在数据库抽象层中。
4。面向对象/函数
我们可以将流程处理拆分成不同的函数调用。每个调用都做一件事情,有时只需要调用其它的函数并且返回结果。
一个很好的例子是在每页中检查一个用户是否已经登录。如果不使用对象或者函数的话,在你的认证系统变动的时候,你就必须在每一页作修改,而不是仅仅改变库中一个函数的调用。在写一段代码之前,你要想一下,如果它在站点中要使用不止一次,你就必须将它移到库中实现。
还有补充吗?
肯定我还有一些地方没有想到,因此请提出你的想法。特别是,你写了一个很大、很复杂的应用,我很想知道如果要你重新再写一次,你会建立怎样的体系并且会做什么改变。

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图