在PHP中使用靈巧的體系結構

很久以前我就想寫這篇文章瞭,但是一直都沒有時間。這裡並不是想要告訴你怎樣做,我希望它可以投石問路,和大傢討論一下如何開發一個好的、擴展性佳的web應用。

  我從事開發已經有2-3年瞭,回望剛開始做的程序,真有點不相信是自己寫的,現在我的web開發技巧已經得到瞭很大的提高,例如sourceForge(http://sourceforge.net/)就是我較為成熟的一個作品,代碼都被分成各種的類和函數。數據庫的結構也很清晰。站點的不同部分都是與其它部分獨立開來的。

  不過這個站點也不是完美的。如果我必需再寫一遍,我將會通過對象或者函數庫的方式,讓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 ("html.php");

//數據訪問庫類
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 (!$field1 || !$field2) {
$feedback="Field 1 And Field 2 Are Required";
return false;
}

//確認用戶有權更新
if (!user_isadmin()) {
$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 (!$result) {
//update failed
return false;
} else {
return true;
}
}

?>
3。便於修改
你當然不會在整個應用中都使用絕對的URL,不過我還要求更進一步,顏色的選擇、元素的名字、字體和其它可能的選項最好也不是絕對的,它們應該在一個配置文件中設置,並且在每一頁中將該文件包含進來。站點的風格也應該獨立開來–這樣你就無需在每個頁面都進行拷貝粘貼的工作,我通常都將這些HTML放在一個函數中,然後就可以在需要時調用。

對於數據庫密碼、數據庫連接等,同樣也放在數據庫抽象層中。

4。面向對象/函數
我們可以將流程處理拆分成不同的函數調用。每個調用都做一件事情,有時隻需要調用其它的函數並且返回結果。

一個很好的例子是在每頁中檢查一個用戶是否已經登錄。如果不使用對象或者函數的話,在你的認證系統變動的時候,你就必須在每一頁作修改,而不是僅僅改變庫中一個函數的調用。在寫一段代碼之前,你要想一下,如果它在站點中要使用不止一次,你就必須將它移到庫中實現。 還有補充嗎?
肯定我還有一些地方沒有想到,因此請提出你的想法。特別是,你寫瞭一個很大、很復雜的應用,我很想知道如果要你重新再寫一次,你會建立怎樣的體系並且會做什麼改變。

發佈留言