以下想法主要以PHP實現(xiàn)為示例，但很多體會我想Java，.NET，Ruby開發(fā)者應該也很容易理解。最后是我對于剛面世就引起無數(shù)人關注的Delphi fo PHP的評測。

WEB程序的架構基本上可以分成以下三類：

(一) 基于"WEB頁面/文件"，例如CGI和PHP/ASP程序。程序的文件分別存儲在不同的目錄里，與URL相對應。當HTTP請求提交至服務器時，URL直接指向某個文件，然后由該文件來處理請求，并返回響應結(jié)果。

比如http://www.website.conm/news/readnews.php?id=1234

可以想像，我們在站點根目錄的news目錄下放置一個readnews.php文件。

這種開發(fā)方式最自然，最易理解，也是PHP最常用的方式。要注意產(chǎn)生的URL對搜索引擎不友好，不過你可以用服務器提供的URL重寫方案來處理，例如Apache的mod_rewrite。

(二) 基于"動作"(Action)。這是MVC架構的WEB程序所采用的最常見的方式。目前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采用這種設計。URL映射到控制器(controller)和控制器中的動作(action)，由action來處理請求并輸出響應結(jié)果。這種設計和上面的基于文件的方式一樣，都是請求/響應驅(qū)動的方案，離不開HTTP。

比如 http://www.website.com/news/read/id/1234

可以想像在實際代碼中，我們會有一個控制器newsController，其中有一個readAction。不同框架可能默認實現(xiàn)方式稍有不同，有的是一個Controller一個文件，其中有多個Action，有的是每個Action一個文件。當然這些你都可以自己控制，題外話。

這種方式的URL通常都很漂亮，對搜索引擎友好，因為很多框架都自帶有URL重寫功能?？梢宰杂梢?guī)定URL中controller、action及參數(shù)出現(xiàn)的位置。

另外，還有更直接的基于URL的設計方案，那就是REST。通過人為規(guī)定URL的構成形式（比如Action限制成只有幾種）來促進網(wǎng)站之間的互相訪問，降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。REST對于Web Services來說是一個創(chuàng)新。

雖然本文討論的是單個項目所采用的架構，而REST是為了解決網(wǎng)站之間的通訊問題，但REST的出現(xiàn)，會對單個項目的架構造成影響（很顯然你在開發(fā)時就要構造規(guī)范的URL）。將來混用REST和MVC應該也是一種趨勢。RoR提供很好的REST支持，Zend Framework也提供了Zend_Rest來支持REST，包括Server和Client。

(三) 基于"組件"（Component ，GUI設計也常稱控件）、事件驅(qū)動的架構，最常見的是微軟的.NET?；舅枷胧前殉绦蚍殖珊芏嘟M件，每個組件都可以觸發(fā)事件，調(diào)用特定的事件處理器來處理（比如在一個HTML按鈕上設置onClick事件鏈接到一個PHP函數(shù)）。這種設計遠離HTTP，HTTP請求完全抽象，映射到一個事件。

事實上這種設計原本最常應用于傳統(tǒng)桌面GUI程序的開發(fā)，例如Delphi，Java Swing等。所有表現(xiàn)層的組件比如窗口，或者HTML表單都可以由IDE來提供，我們只需要在IDE里點擊或拖動鼠標就能夠自動添加一個組件，并且添加一個相應的事件處理器。

這種開發(fā)方式有幾個優(yōu)點：

復用性 -代碼高度可重用。 

易于使用 -通常只需要配置控件的屬性，編寫相關的事件處理函數(shù)。

我個人也挺喜歡這種方式，PEAR就提供了相當強大的HTML_QuickForm，用于在頁面添加表單元素及其事件處理函數(shù)，還可以與Smarty等模板引擎相結(jié)合。這對于項目開發(fā)來說是一個補充性的功能，在項目中的某些部份使用QuickForm，有時可以大大加快開發(fā)。

而完全基于組件和事件驅(qū)動的開發(fā)框架對于PHP來說也已經(jīng)不新鮮，PRADO就是一個這樣的框架，曾經(jīng)得過Zend編程大賽的頭獎。但目前來說很顯然Prado所提倡的這種開發(fā)方式仍然沒有被大部份PHP程序員所接受。為什么呢？

我覺得主要有以下兩個問題：

(1)效率問題

這里指的不是開發(fā)效率，而是代碼的執(zhí)行效率。眾所周知，正常情況下，PHP的執(zhí)行是相當高效的。但是目前這種基于控件的框架效率都成問題。Prado本身提供了一個緩存機制來緩解這個問題。如果不采用緩存，可以說很多站點根本不能使用Prado這樣的框架，比如門戶網(wǎng)站，大型論壇等。

但ASP .NET不太一樣，因為它是編譯型的框架，最后生成的代碼是編譯生成的，不需要再次進行中間過程的諸多處理，所以在第一次執(zhí)行之后速度會很快，執(zhí)行效率還是很高的?！∵@是語言層次的功能，Prado無法通過代碼層次的努力完全彌補。

(2)沒有強大的IDE支持

設置控件的屬性，添加其對應的事件處理器，看似簡單，但控件多了，這也是個繁重的工作。.NET的強大就在于它把程序員從重復的工作中解放了出來，設置屬性很方便，事件處理器也會自動添加。Prado目前沒有這樣的IDE支持。

總之，這種基于控件的框架比較適合于用戶交互較多的，需要對頁面中的很多組件設置不同處理操作，但對于性能要求不高的應用。另外，帶有組件支持的框架通常對AJAX的支持都較好，比如.NET和Ruby on Rails。

綜上，三種架構基本上可以代表目前的所有主流WEB開發(fā)方式，包括PHP,JavaEE,.NET,Ruby/RoR。

目前PHP開發(fā)的狀況和未來的趨勢：

平時做PHP比較多，特別總結(jié)一下PHP開發(fā)的趨勢。目前在PHP開發(fā)中，我們最常用的是基于"文件"的架構，其實也就是一種"面向過程"的開發(fā)方式。通常我們寫PHP程序的目的就是"快點上線，讓程序跑起來"。而且大多數(shù)PHP程序員還要和HTML、CSS做近身搏斗，所以如果程序太抽象，調(diào)整視覺效果就比較困難。所以對于小項目，這是一個最好的選擇。

但越來越多人認識到，面向?qū)ο蠛蚆VC框架更能促進代碼的復用和分享，而且程序易于擴展，隨著程序復雜性的增加這個趨勢越明顯。所以OO框架層出不窮。目前PHP框架當中最有前景的是CakePHP、Symphony和Zend Framework，各自擁有活躍的社區(qū)和龐大的用戶群，都在快速成長當中。PHP的框架都避免走Java框架龐大臃腫的老路，致力于快速開發(fā)，而且主動模仿和吸收RoR這些優(yōu)秀框架的新特性。隨著PHP5的普及和這些框架的成熟，加上PHP原本開發(fā)社區(qū)的龐大人數(shù)，將來也許又會再產(chǎn)生出一些行業(yè)性的標準。

這種選擇適合于中大型項目，特別是需要較大的團隊合作和需要長期維護和二次開發(fā)情況。個人認為這是將來PHP開發(fā)的趨勢。

而對于基于組件和事件驅(qū)動的開發(fā)方式大多數(shù)PHP程序員都不感興趣。但是也有不少人在做這方面的努力，例如Codegear的Delphi for PHP，就吸引了很多人的關注。如果有強大的商業(yè)支持，也許將來在開發(fā)市場也會占一席之地。

我會在下一篇文章介紹D4P的新特性并作評測。

WEB開發(fā)的未來展望：

隨著更貼近HTTP的REST的流行，我覺得像.NET和Java中的抽象組件的方式會受到?jīng)_擊。因為這些組件并不如它們所承諾的那么方便。未來MVC+REST+RIA的模式應該會比較流行。

AJAX是一把雙刃劍，盡管事件驅(qū)動的架構看起來非常適合于處理異步的請求（可以想像頁面中存在幾個組件，每個組件都可以觸發(fā)異步請求，對應對服務器端的某個事件處理器，看起來是很理想的一個處理方式），但要為客戶端自動生成良好的JavaScript代碼是很不容易的，要滿足各種瀏覽器的兼容性要求，還要能夠自己進行擴展，以滿足項目中千奇百怪的需求。 很多時候我更傾向于使用一些JS框架如Prototype來自己開發(fā)各種效果，而不是在服務器端生成。在服務器端生成JS的兩個結(jié)果，一是對生成的代碼不信任，二是人變傻，因為你并不知道真正發(fā)生了什么。

(一點牢騷也貼上來)

關于WEB開發(fā)的個人疑惑：

l 為了讓開發(fā)更簡單，我們不得不學習使用復雜的開發(fā)工具和框架，這到底是一個進步，還是退步？

l IDE讓程序員變聰明還是變傻？ 當我們在服務器代碼里面就可以設計客戶端界面，這是一個進步還是退步？

舉個例子說，微軟的ASP.NET AJAX，讓我們可以在服務器端設計各種異步的控件。那么程序員甚至可以不會Javascript，不懂AJAX就設計出各種客戶端效果。要是哪一天項目需要設計稍復雜的效果，靠IDE和框架無法自動完成，你要怎么辦？　到這個時候再來學JS，也許就遲了。更可怕的是，技術在更新和淘汰，可能十年之后，你會發(fā)現(xiàn)自己除了各種IDE之后，真正精通的技術很少，脫離了IDE你寫一個小程序都要查半天API手冊，因為你平時都是依賴"自動補齊"來寫代碼的！ 這樣的情景，我想沒有人愿意發(fā)生。

也許對于短期開發(fā)的項目來說，是一個進步，但對于程序員個人的成長來說，這并不是好事。對工具的依賴，導致了我們對于底層和核心技術的不求甚解，限制了個人的成長。

最新評論