三種主流WEB架構的開發現狀與未來展望
做WEB好幾年了,各種語言和技術都稍有涉獵。今天心血來潮,突然想總結一下。其實不論什麼技術,什麼需求,通常WEB開發就是透過WEB前端管理一個或大或小或獨立或分散式的關係型資料庫,很多東西都是相通的。這裡說的WEB架構,是指WEB應用開發中每種技術獨有的資源組織形式(包括檔案,資料庫,HTTP請求處理等。注意並非OO的開發方式才有架構一說),也許說開發方式更容易讓人理解一些。
以下想法主要以PHP實現為示例,但很多體會我想Java,.NET,Ruby開發者應該也很容易理解。最後是我對於剛面世就引起無數人關注的Delphi fo PHP的想法。
WEB程式的架構基本上可以分成以下三類:
(一) 基於“WEB頁面/檔案”,例如CGI和PHP/ASP程式。程式的檔案分別儲存在不同的目錄裡,與URL相對應。當HTTP請求提交至伺服器時,URL直接指向某個檔案,然後由該檔案來處理請求,並返回響應結果。
比如
可以想像,我們在站點根目錄的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。
比如
可以想像在實際程式碼中,我們會有一個控制器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開發的個人疑惑:
為了讓開發更簡單,我們不得不學習使用複雜的開發工具和框架,這到底是一個進步,還是退步?
IDE讓程式設計師變聰明還是變傻? 當我們在伺服器程式碼裡面就可以設計客戶端介面,這是一個進步還是退步?
舉個例子說,微軟的ASP.NET AJAX,讓我們可以在伺服器端設計各種非同步的控制元件。那麼程式設計師甚至可以不會Javascript,不懂AJAX就設計出各種客戶端效果。要是哪一天專案需要設計稍複雜的效果,靠IDE和框架無法自動完成,你要怎麼辦? 到這個時候再來學JS,也許就遲了。更可怕的是,技術在更新和淘汰,可能十年之後,你會發現自己除了各種IDE之後,真正精通的技術很少,脫離了IDE你寫一個小程式都要查半天API手冊,因為你平時都是依賴“自動補齊”來寫程式碼的! 這樣的情景,我想沒有人願意發生。
也許對於短期開發的專案來說,是一個進步,但對於程式設計師個人的成長來說,這並不是好事。對工具的依賴,導致了我們對於底層和核心技術的不求甚解,限制了個人的成長。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8271432/viewspace-914381/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 中國物流與供應鏈區塊鏈發展現狀與未來展望(附下載)區塊鏈
- [譯]2018 年 Security Token 發展現狀及未來展望
- CEDEC 2020|日中游戲開發現況與日本未來展望
- 把握現在,掌控未來:2008 Java開發展望Java
- 李開復、LeCun、喬丹三位AI大牛談AI現狀與未來LeCunAI
- 數智洞見 | 資料中臺架構解析及未來展望架構
- Gartner:人工智慧的現狀與未來人工智慧
- 中國人工智慧的現狀與未來!人工智慧
- 智慧家居市場的現狀與未來
- Web開發技術未來的發展Web
- Web開發框架中的架構模式比較(三) (轉)Web框架架構模式
- ERP技術的發展現狀與展望(轉)
- 2021低程式碼現狀:回顧過去,展望未來
- 蘋果企業簽名的現狀與未來蘋果
- 平臺是Web開發的未來嗎?Web
- [轉載]DBA變身架構師? 2011資料庫技術發展現狀與未來趨勢架構資料庫
- 英特爾AI晶片業務的現狀與未來AI晶片
- 未來Web開發趨勢報告Web
- Serverless 的初心、現狀和未來Server
- CMS平臺是Web開發的未來嗎?Web
- 展望未來的「暗黑」類遊戲遊戲
- 展望 C# 7 的未來C#
- 阿里雲架構師解讀三大主流遊戲架構阿里架構遊戲
- SOA:編織未來IT架構架構
- 中國未來經濟架構架構
- 當紅開發語言Go,真的是未來的技術主流嗎?Go
- 單體monolith與微服務架構的四種實現狀態:混亂與有序 - lofidewantoMono微服務架構IDE
- Martin Fowler談Scrum認證、敏捷現狀與未來Scrum敏捷
- 精讀《前端未來展望》前端
- HTML5未來展望HTML
- 業務開發轉基礎開發,這三種「高可用」架構你會麼?架構
- 低程式碼開發平臺會成為未來軟體開發的主流模式嗎模式
- 自動駕駛汽車技術發展現狀,未來已來自動駕駛
- 阿里架構師眼中Dubbo的過去,現在以及未來阿里架構
- 新的一年,來看看大資料與AI的未來展望大資料AI
- iOS 開發(三) MVVM 架構篇iOSMVVM架構
- 全球資訊網之父展望Web未來30年發展:對解決三大難題持樂觀態度Web
- IDC:混合雲和軟體定義是未來數字基礎架構的主流模式架構模式