WEB程序的架構基本上可以分成以下三類：
一 、基於“組件”（Component ，GUI設計也常稱控件）、事件驅動的架構，最常見的是微軟的.NET。基本思想是把程序分成很多組件，每個組件都可以觸發事件，調用特定的事件處理器來處理（比如在一個HTML按鈕上設置onClick事件鏈接到一個PHP函數）。這種設計遠離HTTP，HTTP請求完全抽象，映射到一個事件。
事實上這種設計原本最常應用於傳統桌面GUI程序的開發，例如Delphi，Java Swing等。所有表現層的組件比如窗口，或者HTML表單都可以由IDE來提供，我們只需要在IDE裡點擊或拖動鼠標就能夠自動添加一個組件，並且添加一個相應的事件處理器。
二 、基於“WEB頁面/文件”，例如CGI和PHP/ASP程序。程序的文件分別存儲在不同的目錄裡，與URL相對應。當HTTP請求提交至服務器時，URL直接指向某個文件，然後由該文件來處理請求，並返回響應結果。
比如http://www.website.conm/news/readnews.php?id=1234
可以想像，我們在站點根目錄的news目錄下放置一個readnews.php文件。
這種開發方式最自然，最易理解，也是PHP最常用的方式。要注意產生的URL對搜索引擎不友好，不過你可以用服務器提供的URL重寫方案來處理，例如Apache的mod_rewrite。
三 基於“動作”(Action)。這是MVC架構的WEB程序所採用的最常見的方式。目前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都採用這種設計。URL映射到控制器(controller)和控制器中的動作(action)，由action來處理請求並輸出響應結果。這種設計和上面的基於文件的方式一樣，都是請求/響應驅動的方案，離不開HTTP。
比如 http://www.website.com/news/read/id/1234
可以想像在實際代碼中，我們會有一個控制器newsController，其中有一個readAction。不同框架可能默認實現方式稍有不同，有的是一個Controller一個文件，其中有多個Action，有的是每個Action一個文件。當然這些你都可以自己控制，題外話。
這種方式的URL通常都很漂亮，對搜索引擎友好，因為很多框架都自帶有URL重寫功能。可以自由規定URL中controller、action及參數出現的位置。
另外，還有更直接的基於URL的設計方案，那就是REST。通過人為規定URL的構成形式（比如Action限制成只有幾種）來促進網站之間的互相訪問，降低開發的複雜性，提高系統的可伸縮性。REST對於Web Services來說是一個創新。
雖然本文討論的是單個項目所採用的架構，而REST是為了解決網站之間的通訊問題，但REST的出現，會對單個項目的架構造成影響（很顯然你在開發時就要構造規範的URL）。將來混用REST和MVC應該也是一種趨勢。RoR提供很好的REST支持，Zend Framework也提供了Zend_Rest來支持REST，包括Server和Client。
三代WEB存在的問題：
(1)效率問題
這裡指的不是開發效率，而是代碼的執行效率。眾所周知，正常情況下，PHP的執行是相當高效的。但是目前這種基於控件的框架效率都成問題。Prado本身提供了一個緩存機制來緩解這個問題。如果不採用緩存，可以說很多站點根本不能使用Prado這樣的框架，比如門戶網站，大型論壇等。
但ASP .NET不太一樣，因為它是編譯型的框架，最後生成的代碼是編譯生成的，不需要再次進行中間過程的諸多處理，所以在第一次執行之後速度會很快，執行效率還是很高的。 這是語言層次的功能，Prado無法通過代碼層次的努力完全彌補。
(2)沒有強大的IDE支持
設置控件的屬性，添加其對應的事件處理器，看似簡單，但控件多了，這也是個繁重的工作。.NET的強大就在於它把程序員從重複的工作中解放了出來，設置屬性很方便，事件處理器也會自動添加。Prado目前沒有這樣的IDE支持。
總之，這種基於控件的框架比較適合於用戶交互較多的，需要對頁面中的很多組件設置不同處理操作，但對於性能要求不高的應用。另外，帶有組件支持的框架通常對AJAX的支持都較好，比如.NET和Ruby on Rails。
綜上，三種架構基本上可以代表目前的所有主流WEB開發方式，包括PHP,JavaEE,.NET,Ruby/RoR。
閱讀更多 編程小能手 的文章
