這幾年我比較少寫 PHP 了.有陣子很迷它, 但是因為工作關系, 把較多的時間花在網絡封包和數據庫的分析工作上.而且因為年記較大了所以也很難找到寫程序的工作多半都在做工程師的 “工頭”對于這幾年 PHP 的變化我來不及參與.在這裡收集這幾年對 PHP 的變化, 寫篇心得過過本人自己的乾隱:回顧您以往的職業生涯, 您有好好的管理您寫的 CODE 嗎?還是每次都寫到需求超級肥大了, 才延伸出一大堆的程序碼管理問題.在這裡本人設計一個開發框架的架構, 讓你的程序更簡潔而且讓你的程序更有條有理的被應用.當然這些架構教程我己經簡化很多, 如果放入太多的設計反而會得到反效果.如果您是比較重口味的 PHP 設計者, 先說聲報歉了.如果您常為了需求肥大難以管理你的程序,這篇文章對您來說會是個值得參考的文章, 至少它有著我十幾年的需求開發經驗.一.常見的 PHP 應用的架構:

在往下教程下去前, 本人先定義一些名詞, 以方便大家接下去閱讀教程.

DB :這一塊不用多介紹, 我相信大家對 DB 的經驗獨道, 我們直接跳過去.

Access Layer :這一塊全部都是放一些 Access Logic 在裡頭, 主要的工作是負責跟 DB 還有 MEMCACHE 溝通, 你可以使用現成的開發框架達成這一層的目地, 也可以自己開發.但是這些邏輯建議您都保留在這一層.

MEMCACHE :這一塊主要是做為分散式架構的存取層, 大家有沒有注意到一件事?它是走 TCP 11211 PORT .

它可以用在什麼地方?a.讓你可以把從 DB 的資料撈到快取一份到 MEMCACHE ,來減輕資料庫的工作負擔, 這在大型而且流量很高的系統上, 它辨演很重要的角色就是可以減輕 DB 的工作量.*我們這裡不多介紹 Memcahe 的使用及方式, 您可以多參考官方網站或其它網絡上的教程.b.有一些不用儲存用完就不要的資料, 也可以利用 memcache 直接存取不用再交給 DB 去處理.c.注意一件事:在過去裡我的下屬們在使用它時常會犯一個錯就是爛用 Memcache ,memcache 本身是一個 TCP 的服務在單臺 linux 伺服器下最多只能使用1024個請求, 當然你可以用 ulimit 提高它, 但是請先了解它的本質用對地方.它本身并不能做為程序本身加快程序效能的工具, 但是它是一個可以做到分散式的存取架構, 并且可以減輕 DB 負擔的工具, 的好用工具.所以在使用它時要選對時機, 千萬不要爛用.

Access Layer :這一層的工作主要是存取資料層的邏輯, 我將會2.會有更詳細的說明.

Content Logic Layer :這一層的工作主要是負責處理存取層從 資料層要來的資料的邏輯, 我將會3.會有更詳細的說明.

Presentation Layer :這一層的工作意義重大, 它主要是標準化 Presentation Logic 與 Content Logic Layer 溝通的標準,讓你的畫面邏輯不會愈來愈肥大及復雜, 我將會4.會有更詳細的說明.

Presentation Logic Layer :這一層的工作是做為讓 你的畫面邏輯可以采用標準化的介面來與伺服器溝通, 如果 Presentation Layer 標準化了, 你的畫面邏輯的可重覆利用性就會更高及有彈性, 我將會5.會有更詳細的說明.

Client Layer :這一層就是我們平時便用的瀏覽器,云端服務等等的應用, 相信大家非常了解這一層可以做到的事, 所以我們就不多介紹 Client Layer 了.

二.功能方塊介紹:到這裡我們必需要將圖裡的方塊切的更細讓大家理解請耐心的看完下一張圖:

1. 數據庫邏輯層 :Access Logic Layer 主要的工作是做為與 DB 和 Content Logic 溝通的區塊, 在這裡本人建議大家在設計物件庫或函式庫前, 先參考這個架構.把所有跟資料庫存取的邏輯全部包裝在這個區塊下, 例如大家在設計DB時最愛用 Factory 來做 DB 的切換, 同時把這些邏輯全部整到這一層讓您的程序更有層次更好管理.看到這裡大家一定對一些使用 Factory 設計的 OOP DB 存取函式庫不漠生.這時我要介紹大家一個名詞, Object-relational_mapping :http://en.wikipedia.org/wiki/Object-relational_mapping什麼地方有 ORM ?就是大家常用的.CAKE PHPZEND FRAMEWORK.DoctrinePropelCoughPHPSymphony當然…您也可以自己寫, 重點是, 要懂得怎麼有效率的去管理你的存取層的邏輯.而一但定義了這一層.強烈建議在接下來的 Content Logic Layer , Presentation Logic Layer 嚴格禁止其它邏輯層的邏輯跳過它來存取資料庫.這麼做有什麼好處? :1.確保其它工作者不會寫出不良的DB存取邏輯造成你的系統不好維護2.你可以不用再擔心會有嚴重的存取層 BUG3.它在使用上變的更安全, 不會讓你的資料庫暴露在 Content & Presentation Logic Layer ,讓你的 DB 有一定程度的保障.4.如果你的 ORM TOOL 有提供管理器, 你還可以把所有的 SQL 語法倒出來檢示有沒有什麼存取過重的語法.5.最重要的!!你可以把常用的存取層資料跟 MEMCACHE 做有效的資源管理, 讓你的 DB 的資源更有效的被利用!!補充說明:

Access MYSQL :資料庫的新增改查邏輯全部放在這.

Access Memcache :與 MEMCACHE 存取的新增改查邏輯全部放在這.

Access NOSQL :現在最流行的 NOSQL ,你可以分別的去包裝你要的邏輯在這裡面.

Other :如果你有別的使用資料存取的邏輯, 可以參造上述的方式一一的去整理….

2. 邏輯層 :這一層有什麼東西?1.你們服務用的到的商業邏輯, 你可以把每個商業邏輯用 OOP 設計, 并且放在這一塊, 以利日后的管理.2. String Parser :為什麼在這篇教程裡我會建議您設計這塊? 因為它必需滿足 Presentation Layer 要求的幾個素求:1.一致性高,2.可重覆利用性高, 3.跨平臺性高,4.云端應用, 所以大家不要關掉文章快點看到3.怎麼讓你的系統可以符合這四個素求.3.表示層:我為何在這篇教程裡, 放入了這一層的應用?

這要回顧到10年前, 我入手了一本 Wrox 的 Professional PHP4.這本書我印象深刻, 因為它一共有十一個作者在寫: 當時看到它有一篇單元 “多層式架構開發” ,讓我對整個 WEB 架構開發的視野完全打開.不過我得承認我以前很嘴賤, 常說 SMARTY TEMPLATE 是玩具.PS : SMARTY TEMPLATE 采用 tpl php var 的方式來做少了這一層,常會極端的用些言語說它不好.你可以參考這二本書, 會發現這一層放入這個設計會讓你未來工作變的輕松很多.http://www.amazon.com/Profession … homas/dp/1861006918http://www.amazon.com/Profession … p;keywords=PHP4+XML#回到正題-這一層專門用來處理 Content Logic Layer 處理好的資料, 利用 XML , JSON 等標準化的介面語言, 來規范你的 Content Logic Layer 按照你的 Convention (規范)來吐出資料給 Presentation Logic Layera.這樣做有什麼好處：1.一致性高:也因為這樣, 你的 Presentation Layer 有著標準化的格式, 所以你在使用 AJAX , AS , PHP SDK 等…做畫面邏輯串接時,你的畫面邏輯的程序將會變的一致性很高, 因為都是參考同樣的格式, 讓你的畫面邏輯的程序不會亂長.工程師因為熟悉相同的介面格式, 工作起來將會非常的輕松.2.可重覆利用性高:在你享受 Presentation Layer 有著標準化的格式的好處時, 你會發現,你可以把畫面邏輯也整理起來重覆利用,這時你會發現你少寫好多好多的程序碼.例如: 換頁邏輯, 表單的呈現………..等等等, 只要另外塞 CSS 進來就好了. 根本不用寫什麼程序.3.跨平臺性高:啥咪?還有.是的!!!大家記得 RSS 嗎? RSS就是利用了 Presentation Layer 這個特性讓各種平臺都可以串接 BLOG 的文章內容, 讓你的系統有著強大的夸平臺性整合能力.4.云端應用:是的即然跨平臺性高了, 也就是你完成這個需求的同時, 你所有的系統內容的呈現可以丟給任何云端平臺的整合!b.使用心得：這個設計, 會讓你的系統架構非常靈活, 靈活到什麼程度?以往一組新增/修改/刪除/換頁/搜尋, 只要寫完一次而且完整的從下到上每一層整合上來.我幾乎不用二次開發, 直接套用之前寫好的 content Logic , Presentation Logic 就可以完成一個需求.一天可以完工三十幾組新增/修改/刪除/換頁/搜尋的串接, 所以我當時消耗需求的速度比起一般沒有用這個設計技巧快上非常的多.而大家心裡會有疑問, 這不就是以前 RUBY & CAKE PHP 的特性嗎?是的!!就這個理念!不過有差異, 就是 CAKE PHP 在做畫面邏輯時, 它并不會真的把這層切開, 而是將 MVC 裡的 V 和 C 有效化的重覆利用, 但是一但要使用云端應用和夸平臺時,之前寫過的程序無法直接透過 Presentation Layer 拉出去給第三方平臺做串接.雖然省了 ORM 那一層的重覆開發, 但是 Content Layer 和 Presentation Layer 還是要在手工調整的.而一但一調整, 就會產生, DEBUG ,開發, 穩定性, 和你又多了一堆CODE 要維護的工作….4. 表現邏輯層 :這一層講起來輕松多了, 因為大家己經有了非常多的 AJAX , XSL , FACEBOOK SDK , IOS , ANDROID , FLASH AS 的串接經驗.沒錯, 這裡就是把之前辛苦定義并且做好的 Presentation Layer 吐出來的格式做應用.你可以透過~HTTP , SOCKET SERVER 等等..將你的 Presentation Layer 的 JSON , XML 吐出來, 并且交給你的畫面邏輯程序去串接.這麼一來你也輕松完成了一個云端的整合介面, 讓你寫的 PHP 可以廣泛的使用在任何不同的平臺上.5. 單元測試/壓力測試/集成測試:在我開發每一層的元件時, 我都會要求工程師, 做單元測試(UNIT TEST), 壓力測試( Stress Test ), 整合測試( Integration Test )a.單元測試(UNIT TEST): 你可以使用 PHPUNIT 或是自己寫, 針對你的一個函數的進和出的測試, 并且預先寫好 TEST CASE ,確保每一層的函式庫都是非常穩定而且沒有問題的, 來讓你管理程序的品質.b.壓力測試(Stess TEST): 針對每一個函式庫的邏輯, 在做 UNIT TEST 的同時, 將 STRESS TEST 的 TEST CASE 喂進去, 并且記錄每一個函式處理 TEST 所消耗的時間.c.整合測試(Integration Test): 你可以寫一支程序, 做 DAILY BUILD 每天去檢查所有程序設計師 COMMIT 到 SVN 的程序碼是否有問題, 確保每個函式之間整合是正常的, 降低 DEBUG 的工作量.