WEB軟體結構原則

一、 目錄結構清楚，不宜過深，複雜，路徑最好用相對位址 
二、 命名適當 
三、 常變內容、介面使模板較好 
四、 共公資訊統一儲存 
五、 Include檔案不可嵌入較多 
六、 目錄下不可儲存太多內容檔案 
七、 資料結構要設計合理 
八、 資料校正應在伺服器端 
九、 串連資料庫近晚，中斷連線近早 
十、 盡量少使用SESSION與COOKIE 

詳細說明： 

(一) 目錄結構清楚，不宜過深，複雜，路徑最好用相對位址 
a) 什麼樣的目錄放什麼樣的內容，這樣便於管理，使WEB程式的目錄結構，清楚明了，一看便知道某個檔案夾下儲存了哪些功能模組與內容。若隨便存放，時間一長久自己都將不從瞭解某目錄是用來做什麼的。如：經常要使用的可執行檔最要存放在（項目根目錄）根目錄，這樣做主要是便於瞭解其作用，同時也為在程式中少輸入些地址字元。程式所用到的圖片統一存放在根目錄下images目錄中，若項目較大，分枝較多，可再在其目錄下建立也分枝程式相關的目錄名，儲存相關的圖片內容。程式的設定檔與常用共公函數類庫存放在include目錄中，存放在此目錄下的函數類庫副檔名得命名為：.php切不命名為.inc .ini之類為副檔名的檔案，主要是防此此類檔案可供使用者下載，或查閱其源碼內容，這樣對其調用方便明確。模板檔案應儲存在根目錄下templates目錄中，副檔名為.html，如果項目較大，分類較多，模板檔案可分類存放在下極目錄中。臨時檔案儲存體在根目錄tmp目錄中，此目錄通常設定為任何人都可讀可寫。使用相對位址主要是方便程式移植。

 (二) 命名適當 
a) 命名最好是以程式用來作什麼用來命名。若一個單詞就要描述則用小寫單詞來命名，若要用多個單詞方能代表，也以小寫單詞之間加底線串連。要注意命名不可過長，這樣就不方便了，雖然能表達的更明確，但打字難打啊。程式中函數命名也可與此相同。不好之上也有，那就是每次命名都得要花時間去想個較合適的名字，由其是對於是我們這種英文水評較差的人來說可不是一件容易的事啊。（慘啊，哈哈！） 

(三) 常變內容、介面使模板較好 
a) 常變內容、介面使用模板較好，這是因為當我某天感覺某不頁面不美觀時尚時，我想更換較新較好的介面，這時就用得上了。如果是按照傳統的製作將HTML頁面內容放在程式中處理輸入時，較麻煩非得要更改程式不可，這可能會帶來較大的不便萬一更改出錯，這就不太好了。（程式有很長一段時沒有維護了，突然要改，一時之間是難免不發生改錯的情況發生）。若是使用了模板則不用改程式，只要更改一下模板檔案就行了。好了說了這麼我模板的好處，好像傳統的做法沒有一點好處是的，好像分文不值是的，也不是，模板也有它不好的地方，現在我也來說說它是怎麼個不好的。傳統做法是把HTML代碼嵌入在WEB程式中，這樣做的好處是，執行速度要比使用模板的要快，這是因為它不用經過任何處理就能直接輸出，而模板就不一樣啦。模板先要開啟讀模數板檔案到字串變數可數組字串變數中，這是要時間的吧？讀處完了之後還得花時間用字串操作函數替換模板中模板變數吧？替換完成了方能進入輸出。傳統做法與使用模板作法，您覺得哪個好呢？（我個人認為如果是開發訪問量相當大的網站，選擇傳統的作法是一個不錯的選擇，我所說的是相對不是絕對，如果訪問量再大那就不能用指令碼語言去寫了，那得用CGI + Socket + Demon了。不說了，說遠了，哈哈） 

(四) 共公資訊統一儲存 
a) 共公資訊統一儲存，這主要為了方便團隊開發時都能進行調用用的最常的函數，不用每個開發人員都複製一份或自己寫一份儲存在程式檔案中，這樣做浪費空間同時效率效果也不好。 

(五) Include檔案不可嵌入較多 
a) Include檔案不可嵌入較多，這是因為每次程式include某個檔案時，是要開啟讀取這個檔案的，這是要時間的哦，再就是說處理路徑時可能會遇到較難發現的BUG問題。 

(六) 目錄下不可儲存太多內容檔案 
a) 目錄下不可儲存太多內容檔案，你有沒有發現？每當你進入windows的system32檔案夾時通常開啟的時間要比開啟其它檔案夾時要長久點呢？這主要是因為system32這個檔案夾中檔案較多，當你開啟系統得花時間尋找檔案並顯示吧？如果檔案較多較大時最好是分目錄分盤符來處理。假若您的機器夠好夠強勁的話，就當我沒說過，那就得另當別論了。 

(七) 資料結構要設計合理 
a) 資料結構要設計合理，如果資料結構設計不合理的話，不管你的程式寫的多精典，寫得我容易，也不是不能發揮其最大作用與價值的。這就相當於一個女人的胸部最大最豐滿，但人不夠高，而且又黑，身體又不好，身架又殘疾，你會說她美麗完美嗎？程式也一樣，有些代碼沉長又不起作用，存在也沒有什麼用。資料結構要精簡明了。 

(八) 資料校正應在伺服器端

a) 資料校正應在伺服器端，這是因為就算是他人不從我們的頁面輸入資料，自己做了個連結地址(GET)或自己做了個表單用POST方式傳送資料，我們的程式也將進入核對查驗。若是放在用戶端，他人就能用以上方法逃過審核了。但這樣做也有他不好之處，那就是當資料量大時，伺服器會負載運行，審核心數據完整性是可開銷時間與系統資源的。在用戶端就不會佔用伺服器太多的資源，因為他佔用的是使用者的資源。 

(九) 串連資料庫近晚，中斷連線近早 
a) 串連資料庫近晚，中斷連線近早，這主要是因為串連資料是要時間的吧？串連上了不即時使用也要佔用系統資源吧？串連資料庫連接數量是有限制的吧？所以得盡晚串連，儘早中斷連線，這個做能使佔用系統資源最少，為下一次串連提供條件。 

(十) 盡量少使用SESSION與COOKIE 
a) 盡量少使用SESSION與COOKIE，因為使用SESSION是要佔用系統資源的，SESSION是儲存在伺服器端的，每次讀取SESSION中的資料是要較大開銷的。COOKIE雖然不佔用伺服器資源，但COOKIE不太安全。