很早就想寫這篇文章了，但一直沒有時間完成它。不是說我來告訴大家如何做，我更希望本文只是做為一個引子，與大家來討論關於如何建立一個有效地、靈活的網絡應用程序。
經過了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或查詢數據庫來完成這個功能，但一旦你想改變你的驗證系統，你不得不改動每一個頁面，其實你應該可以通過改動函數庫裡一個普通的函數就完成這個變動的。任何時候，你寫一段代碼，如果它將會被用於多於一個地方，你就要考慮把它放入一個庫裡了。
其它還有什麼？
顯然還有很多我沒有談到的事，告訴我你的想法，我將在下一篇文章中來討論它們。特別地是，如果你寫了一個大型的、復雜的應用程序，我想聽聽你是如何規劃它的及你重做時不什麼不同的想法。
