關(guān)于三種主流WEB架構的思考
Haohappy haohappy AT msn.com
轉載請注明來(lái)源：http://blog.csdn.net/haohappy2004
做WEB好幾年了，各種語(yǔ)言和技術(shù)都稍有涉獵。今天心血來(lái)潮，突然想總結一下。其實(shí)不論什么技術(shù)，什么需求，通常WEB開(kāi)發(fā)就是通過(guò)WEB前端管理一個(gè)或大或小或獨立或分布式的關(guān)系型數據庫，很多東西都是相通的。這里說(shuō)的WEB架構，是指WEB應用開(kāi)發(fā)中每種技術(shù)獨有的資源組織形式（包括文件，數據庫，HTTP請求處理等。注意并非OO的開(kāi)發(fā)方式才有架構一說(shuō)），也許說(shuō)開(kāi)發(fā)方式更容易讓人理解一些。
以下想法主要以PHP實(shí)現為示例，但很多體會(huì )我想Java，.NET，Ruby開(kāi)發(fā)者應該也很容易理解。最后是我對于剛面世就引起無(wú)數人關(guān)注的Delphi fo PHP的評測。
WEB程序的架構基本上可以分成以下三類(lèi)：
(一) 基于“WEB頁(yè)面/文件”，例如CGI和PHP/ASP程序。程序的文件分別存儲在不同的目錄里，與URL相對應。當HTTP請求提交至服務(wù)器時(shí)，URL直接指向某個(gè)文件，然后由該文件來(lái)處理請求，并返回響應結果。
比如http://www.website.conm/news/readnews.php?id=1234
可以想像，我們在站點(diǎn)根目錄的news目錄下放置一個(gè)readnews.php文件。
這種開(kāi)發(fā)方式最自然，最易理解，也是PHP最常用的方式。要注意產(chǎn)生的URL對搜索引擎不友好，不過(guò)你可以用服務(wù)器提供的URL重寫(xiě)方案來(lái)處理，例如Apache的mod_rewrite。
(二) 基于“動(dòng)作”(Action)。這是MVC架構的WEB程序所采用的最常見(jiàn)的方式。目前主流的WEB框架像Struts、Webwork(Java)，Ruby onRails(Ruby),ZendFramework(PHP)等都采用這種設計。URL映射到控制器(controller)和控制器中的動(dòng)作(action)，由action來(lái)處理請求并輸出響應結果。這種設計和上面的基于文件的方式一樣，都是請求/響應驅動(dòng)的方案，離不開(kāi)HTTP。
比如 http://www.website.com/news/read/id/1234
可以想像在實(shí)際代碼中，我們會(huì )有一個(gè)控制器newsController，其中有一個(gè)readAction。不同框架可能默認實(shí)現方式稍有不同，有的是一個(gè)Controller一個(gè)文件，其中有多個(gè)Action，有的是每個(gè)Action一個(gè)文件。當然這些你都可以自己控制，題外話(huà)。
這種方式的URL通常都很漂亮，對搜索引擎友好，因為很多框架都自帶有URL重寫(xiě)功能?？梢宰杂梢幎║RL中controller、action及參數出現的位置。
另外，還有更直接的基于URL的設計方案，那就是REST。通過(guò)人為規定URL的構成形式（比如Action限制成只有幾種）來(lái)促進(jìn)網(wǎng)站之間的互相訪(fǎng)問(wèn)，降低開(kāi)發(fā)的復雜性，提高系統的可伸縮性。REST對于Web Services來(lái)說(shuō)是一個(gè)創(chuàng )新。
雖然本文討論的是單個(gè)項目所采用的架構，而REST是為了解決網(wǎng)站之間的通訊問(wèn)題，但REST的出現，會(huì )對單個(gè)項目的架構造成影響（很顯然你在開(kāi)發(fā)時(shí)就要構造規范的URL）。將來(lái)混用REST和MVC應該也是一種趨勢。RoR提供很好的REST支持，ZendFramework也提供了Zend_Rest來(lái)支持REST，包括Server和Client。
(三) 基于“組件”（Component ，GUI設計也常稱(chēng)控件）、事件驅動(dòng)的架構，最常見(jiàn)的是微軟的.NET?；舅枷胧前殉绦蚍殖珊芏嘟M件，每個(gè)組件都可以觸發(fā)事件，調用特定的事件處理器來(lái)處理（比如在一個(gè)HTML按鈕上設置onClick事件鏈接到一個(gè)PHP函數）。這種設計遠離HTTP，HTTP請求完全抽象，映射到一個(gè)事件。
事實(shí)上這種設計原本最常應用于傳統桌面GUI程序的開(kāi)發(fā)，例如Delphi，Java Swing等。所有表現層的組件比如窗口，或者HTML表單都可以由IDE來(lái)提供，我們只需要在IDE里點(diǎn)擊或拖動(dòng)鼠標就能夠自動(dòng)添加一個(gè)組件，并且添加一個(gè)相應的事件處理器。
這種開(kāi)發(fā)方式有幾個(gè)優(yōu)點(diǎn)：
· 復用性 -代碼高度可重用。
· 易于使用 -通常只需要配置控件的屬性，編寫(xiě)相關(guān)的事件處理函數。
我個(gè)人也挺喜歡這種方式，PEAR就提供了相當強大的HTML_QuickForm，用于在頁(yè)面添加表單元素及其事件處理函數，還可以與Smarty等模板引擎相結合。這對于項目開(kāi)發(fā)來(lái)說(shuō)是一個(gè)補充性的功能，在項目中的某些部份使用QuickForm，有時(shí)可以大大加快開(kāi)發(fā)。
而完全基于組件和事件驅動(dòng)的開(kāi)發(fā)框架對于PHP來(lái)說(shuō)也已經(jīng)不新鮮，PRADO就是一個(gè)這樣的框架，曾經(jīng)得過(guò)Zend編程大賽的頭獎。但目前來(lái)說(shuō)很顯然Prado所提倡的這種開(kāi)發(fā)方式仍然沒(méi)有被大部份PHP程序員所接受。為什么呢？
我覺(jué)得主要有以下兩個(gè)問(wèn)題：
(1)效率問(wèn)題
這里指的不是開(kāi)發(fā)效率，而是代碼的執行效率。眾所周知，正常情況下，PHP的執行是相當高效的。但是目前這種基于控件的框架效率都成問(wèn)題。Prado本身提供了一個(gè)緩存機制來(lái)緩解這個(gè)問(wèn)題。如果不采用緩存，可以說(shuō)很多站點(diǎn)根本不能使用Prado這樣的框架，比如門(mén)戶(hù)網(wǎng)站，大型論壇等。
但ASP .NET不太一樣，因為它是編譯型的框架，最后生成的代碼是編譯生成的，不需要再次進(jìn)行中間過(guò)程的諸多處理，所以在第一次執行之后速度會(huì )很快，執行效率還是很高的?！∵@是語(yǔ)言層次的功能，Prado無(wú)法通過(guò)代碼層次的努力完全彌補。
(2)沒(méi)有強大的IDE支持
設置控件的屬性，添加其對應的事件處理器，看似簡(jiǎn)單，但控件多了，這也是個(gè)繁重的工作。.NET的強大就在于它把程序員從重復的工作中解放了出來(lái)，設置屬性很方便，事件處理器也會(huì )自動(dòng)添加。Prado目前沒(méi)有這樣的IDE支持。
總之，這種基于控件的框架比較適合于用戶(hù)交互較多的，需要對頁(yè)面中的很多組件設置不同處理操作，但對于性能要求不高的應用。另外，帶有組件支持的框架通常對AJAX的支持都較好，比如.NET和Ruby on Rails。
綜上，三種架構基本上可以代表目前的所有主流WEB開(kāi)發(fā)方式，包括PHP,JavaEE,.NET,Ruby/RoR。
目前PHP開(kāi)發(fā)的狀況和未來(lái)的趨勢：
平時(shí)做PHP比較多，特別總結一下PHP開(kāi)發(fā)的趨勢。目前在PHP開(kāi)發(fā)中，我們最常用的是基于“文件”的架構，其實(shí)也就是一種“面向過(guò)程”的開(kāi)發(fā)方式。通常我們寫(xiě)PHP程序的目的就是“快點(diǎn)上線(xiàn)，讓程序跑起來(lái)”。而且大多數PHP程序員還要和HTML、CSS做近身搏斗，所以如果程序太抽象，調整視覺(jué)效果就比較困難。所以對于小項目，這是一個(gè)最好的選擇。
但越來(lái)越多人認識到，面向對象和MVC框架更能促進(jìn)代碼的復用和分享，而且程序易于擴展，隨著(zhù)程序復雜性的增加這個(gè)趨勢越明顯。所以OO框架層出不窮。目前PHP框架當中最有前景的是CakePHP、Symphony和ZendFramework，各自擁有活躍的社區和龐大的用戶(hù)群，都在快速成長(cháng)當中。PHP的框架都避免走Java框架龐大臃腫的老路，致力于快速開(kāi)發(fā)，而且主動(dòng)模仿和吸收RoR這些優(yōu)秀框架的新特性。隨著(zhù)PHP5的普及和這些框架的成熟，加上PHP原本開(kāi)發(fā)社區的龐大人數，將來(lái)也許又會(huì )再產(chǎn)生出一些行業(yè)性的標準。
這種選擇適合于中大型項目，特別是需要較大的團隊合作和需要長(cháng)期維護和二次開(kāi)發(fā)情況。個(gè)人認為這是將來(lái)PHP開(kāi)發(fā)的趨勢。
而對于基于組件和事件驅動(dòng)的開(kāi)發(fā)方式大多數PHP程序員都不感興趣。但是也有不少人在做這方面的努力，例如Codegear的Delphi for PHP，就吸引了很多人的關(guān)注。如果有強大的商業(yè)支持，也許將來(lái)在開(kāi)發(fā)市場(chǎng)也會(huì )占一席之地。
我會(huì )在下一篇文章介紹D4P的新特性并作評測。
WEB開(kāi)發(fā)的未來(lái)展望：
隨著(zhù)更貼近HTTP的REST的流行，我覺(jué)得像.NET和Java中的抽象組件的方式會(huì )受到?jīng)_擊。因為這些組件并不如它們所承諾的那么方便。未來(lái)MVC+REST+RIA的模式應該會(huì )比較流行。
AJAX是一把雙刃劍，盡管事件驅動(dòng)的架構看起來(lái)非常適合于處理異步的請求（可以想像頁(yè)面中存在幾個(gè)組件，每個(gè)組件都可以觸發(fā)異步請求，對應對服務(wù)器端的某個(gè)事件處理器，看起來(lái)是很理想的一個(gè)處理方式），但要為客戶(hù)端自動(dòng)生成良好的JavaScript代碼是很不容易的，要滿(mǎn)足各種瀏覽器的兼容性要求，還要能夠自己進(jìn)行擴展，以滿(mǎn)足項目中千奇百怪的需求。很多時(shí)候我更傾向于使用一些JS框架如Prototype來(lái)自己開(kāi)發(fā)各種效果，而不是在服務(wù)器端生成。在服務(wù)器端生成JS的兩個(gè)結果，一是對生成的代碼不信任，二是人變傻，因為你并不知道真正發(fā)生了什么。
(一點(diǎn)牢騷也貼上來(lái))
關(guān)于WEB開(kāi)發(fā)的個(gè)人疑惑：
l 為了讓開(kāi)發(fā)更簡(jiǎn)單，我們不得不學(xué)習使用復雜的開(kāi)發(fā)工具和框架，這到底是一個(gè)進(jìn)步，還是退步？
l IDE讓程序員變聰明還是變傻？ 當我們在服務(wù)器代碼里面就可以設計客戶(hù)端界面，這是一個(gè)進(jìn)步還是退步？
舉個(gè)例子說(shuō)，微軟的ASP.NETAJAX，讓我們可以在服務(wù)器端設計各種異步的控件。那么程序員甚至可以不會(huì )Javascript，不懂AJAX就設計出各種客戶(hù)端效果。要是哪一天項目需要設計稍復雜的效果，靠IDE和框架無(wú)法自動(dòng)完成，你要怎么辦？ 到這個(gè)時(shí)候再來(lái)學(xué)JS，也許就遲了。更可怕的是，技術(shù)在更新和淘汰，可能十年之后，你會(huì )發(fā)現自己除了各種IDE之后，真正精通的技術(shù)很少，脫離了IDE你寫(xiě)一個(gè)小程序都要查半天API手冊，因為你平時(shí)都是依賴(lài)“自動(dòng)補齊”來(lái)寫(xiě)代碼的！這樣的情景，我想沒(méi)有人愿意發(fā)生。
也許對于短期開(kāi)發(fā)的項目來(lái)說(shuō)，是一個(gè)進(jìn)步，但對于程序員個(gè)人的成長(cháng)來(lái)說(shuō)，這并不是好事。對工具的依賴(lài)，導致了我們對于底層和核心技術(shù)的不求甚解，限制了個(gè)人的成長(cháng)。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1586750
聯(lián)系客服
