關於三種主流WEB架構的思考

轉載鏈接：http://www.jb51.net/article/14202.htm

 

　　作WEB好幾年了，各類語言和技術都稍有涉獵。今天心血來潮，忽然想總結一下。其實不論什麼技術，什麼需求，一般WEB開發就是經過WEB前端管理一個或大或小或獨立或分佈式的關係型數據庫，不少東西都是相通的。這裏說的WEB架構，是指WEB應用開發中每種技術獨有的資源組織形式（包括文件，數據庫，HTTP請求處理等。注意並不是OO的開發方式纔有架構一說），也許說開發方式更容易讓人理解一些。 -  如下想法主要以PHP實現爲示例，但不少體會我想Java，.NET，Ruby開發者應該也很容易理解。最後是我對於剛面世就引發無數人關注的Delphi fo PHP的評測。

WEB程序的架構基本上能夠分紅如下三類：

　　(一) 基於"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。

 

　　(三) 基於"組件"（Component ，GUI設計也常稱控件）、事件驅動的架構，最多見的是微軟的.NET。基本思想是把程序分紅不少組件，每一個組件均可以觸發事件，調用特定的事件處理器來處理（好比在一個HTML按鈕上設置onClick事件連接到一個PHP函數）。這種設計遠離HTTP，HTTP請求徹底抽象，映射到一個事件。

事實上這種設計本來最常應用於傳統桌面GUI程序的開發，例如Delphi，Java Swing等。全部表現層的組件好比窗口，或者HTML表單均可以由IDE來提供，咱們只須要在IDE裏點擊或拖動鼠標就可以自動添加一個組件，而且添加一個相應的事件處理器。

這種開發方式有幾個優勢：

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

易於使用 -一般只須要配置控件的屬性，編寫相關的事件處理函數。

 

我我的也挺喜歡這種方式，PEAR就提供了至關強大的HTML_QuickForm，用於在頁面添加表單元素及其事件處理函數，還能夠與Smarty等模板引擎相結合。這對於項目開發來講是一個補充性的功能，在項目中的某些部份使用QuickForm，有時能夠大大加快開發。

而徹底基於組件和事件驅動的開發框架對於PHP來講也已經不新鮮，PRADO就是一個這樣的框架，曾經得過Zend編程大賽的頭獎。但目前來講很顯然Prado所提倡的這種開發方式仍然沒有被大部份PHP程序員所接受。爲何呢？

 

我以爲主要有如下兩個問題：

(1)效率問題

這裏指的不是開發效率，而是代碼的執行效率。衆所周知，正常狀況下，PHP的執行是至關高效的。可是目前這種基於控件的框架效率都成問題。Prado自己提供了一個緩存機制來緩解這個問題。若是不採用緩存，能夠說不少站點根本不能使用Prado這樣的框架，好比門戶網站，大型論壇等。

但ASP .NET不太同樣，由於它是編譯型的框架，最後生成的代碼是編譯生成的，不須要再次進行中間過程的諸多處理，因此在第一次執行以後速度會很快，執行效率仍是很高的。　這是語言層次的功能，Prado沒法經過代碼層次的努力徹底彌補。

(2)沒有強大的IDE支持

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

總之，這種基於控件的框架比較適合於用戶交互較多的，須要對頁面中的不少組件設置不一樣處理操做，但對於性能要求不高的應用。另外，帶有組件支持的框架一般對AJAX的支持都較好，好比.NET和Ruby on Rails。

 

綜上，三種架構基本上能夠表明目前的全部主流WEB開發方式，包括PHP,JavaEE,.NET,Ruby/RoR。

 

//**************************************************************************************// 

//**************************************************************************************// 

//**************************************************************************************//

 

 

目前PHP開發的情況和將來的趨勢：

　　平時作PHP比較多，特別總結一下PHP開發的趨勢。目前在PHP開發中，咱們最經常使用的是基於"文件"的架構，其實也就是一種"面向過程"的開發方式。一般咱們寫PHP程序的目的就是"快點上線，讓程序跑起來"。並且大多數PHP程序員還要和HTML、CSS作近身搏鬥，因此若是程序太抽象，調整視覺效果就比較困難。因此對於小項目，這是一個最好的選擇。

　　但愈來愈多人認識到，面向對象和MVC框架更能促進代碼的複用和分享，並且程序易於擴展，隨着程序複雜性的增長這個趨勢越明顯。因此OO框架層出不窮。目前PHP框架當中最有前景的是CakePHP、Symphony和Zend Framework，各自擁有活躍的社區和龐大的用戶羣，都在快速成長當中。PHP的框架都避免走Java框架龐大臃腫的老路，致力於快速開發，並且主動模仿和吸取RoR這些優秀框架的新特性。隨着PHP5的普及和這些框架的成熟，加上PHP本來開發社區的龐大人數，未來也許又會再產生出一些行業性的標準。

　　這種選擇適合於中大型項目，特別是須要較大的團隊合做和須要長期維護和二次開發狀況。我的認爲這是未來PHP開發的趨勢。

而對於基於組件和事件驅動的開發方式大多數PHP程序員都不感興趣。可是也有很多人在作這方面的努力，例如Codegear的Delphi for PHP，就吸引了不少人的關注。若是有強大的商業支持，也許未來在開發市場也會佔一席之地。

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

 

WEB開發的將來展望：

　　隨着更貼近HTTP的REST的流行，我以爲像.NET和Java中的抽象組件的方式會受到衝擊。由於這些組件並不如它們所承諾的那麼方便。將來MVC+REST+RIA的模式應該會比較流行。

AJAX是一把雙刃劍，儘管事件驅動的架構看起來很是適合於處理異步的請求（能夠想像頁面中存在幾個組件，每一個組件均可以觸發異步請求，對應對服務器端的某個事件處理器，看起來是很理想的一個處理方式），但要爲客戶端自動生成良好的JavaScript代碼是很不容易的，要知足各類瀏覽器的兼容性要求，還要可以本身進行擴展，以知足項目中千奇百怪的需求。 不少時候我更傾向於使用一些JS框架如Prototype來本身開發各類效果，而不是在服務器端生成。在服務器端生成JS的兩個結果，一是對生成的代碼不信任，二是人變傻，由於你並不知道真正發生了什麼。

 

(一點牢騷也貼上來)

關於WEB開發的我的疑惑：

l 爲了讓開發更簡單，咱們不得不學習使用複雜的開發工具和框架，這究竟是一個進步，仍是退步？

l IDE讓程序員變聰明仍是變傻？ 當咱們在服務器代碼裏面就能夠設計客戶端界面，這是一個進步仍是退步？

舉個例子說，微軟的ASP.NET AJAX，讓咱們能夠在服務器端設計各類異步的控件。那麼程序員甚至能夠不會Javascript，不懂AJAX就設計出各類客戶端效果。要是哪一天項目須要設計稍複雜的效果，靠IDE和框架沒法自動完成，你要怎麼辦？　到這個時候再來學JS，也許就遲了。更可怕的是，技術在更新和淘汰，可能十年以後，你會發現本身除了各類IDE以後，真正精通的技術不多，脫離了IDE你寫一個小程序都要查半天API手冊，由於你平時都是依賴"自動補齊"來寫代碼的！ 這樣的情景，我想沒有人願意發生。

也許對於短時間開發的項目來講，是一個進步，但對於程序員我的的成長來講，這並非好事。對工具的依賴，致使了咱們對於底層和核心技術的不求甚解，限制了我的的成長。