Java Web開發構想(1) -- 1.背景、形勢 2.Web開發框架層次概述

發表時間：2005-5-30

發布人：葵宇科技

浏覽次數：47

Java Web開發構想

1．背景、形勢

能夠進行Web開發的編程語言和(hé)技術(shù)很多

(1) 動(dòng)态解釋語言

PHP; Perl; Python (Zope, Plone); Ruby (Ruby style="MARGIN: 0in 0in 0pt">(2) 編譯語言

Java; .net

Java Web開發遠(yuǎn)非一枝獨秀：

除了受到來自.net 這個(gè)重量級對手的最大挑戰之外，更受到Zope, Ruby style="FONT-FAMILY: 宋體; mso-ascii-font-family: "Times New Roman"; mso-hansi-font-family: "Times New Roman"">等新式輕騎兵(bīng)的沖擊（當然，也繼續受到老式輕步兵(bīng)PHP, Perl的沖擊）。

官方Java走的是複雜路(lù)線，Servlet -> JSP -> Taglib。.net走的也是複雜路(lù)線，依靠成熟友好的集成化開發環境取勝。Java陣營好容易應對過來，從紛纭複雜的各種開發框架基礎上，發展出了重量級Web開發框架JSF，以及相應的集成化開發環境；渴望以此應對.net的攻勢。勝負未分，前途未蔔。這時，另一個(gè)方向又殺來了新式輕騎Zope, Ruby style="FONT-FAMILY: 宋體; mso-ascii-font-family: "Times New Roman"; mso-hansi-font-family: "Times New Roman"">。

Python, Ruby等動(dòng)态解釋語言，面向對象特性更好，先天支持動(dòng)态綁定、AOP、函數式編程、“編程即配置”等時髦概念。開發速度更快，代碼量更小，達到killer級别。

傳統的HTML Web開發領域裡面，Java已經是腹背受敵。領域外也展開了征戰，Rich Client Architecture的興起：AJAX(XMLHttp), Flash RIA, XUL, XAML, Smart Client（以及從前的ActiveX, Applet, Web Start）。

Web的發展趨勢是語義Web，最終目的是讓整個(gè)Web成為一個(gè)巨大的數據庫。

這意味着，未來的Web應用将更加的面向文(wén)本内容數據，更加搜索引擎友好 – Search Engine Friendly.

二進制的客戶端插件，如(rú)Flash RIA, ActiveX, Applet, Web Start等，雖然交互性能最好，但不是以文(wén)本内容數據為中(zhōng)心，搜索引擎不友好。所以，我隻是保持适當關(guān)注。我更關(guān)注基于文(wén)本的UI表現，如(rú)HTML, XUL, XAML等。XUL, XAML還沒有廣泛流行，隻是保持一種有興趣的關(guān)注。

當下(xià)關(guān)注的重點，還是 XHTML + CSS + Javascript少(shǎo)量的 AJAX(XMLHttp)增加更好的交互性。

我一直認為：輕量、簡潔、高效才是硬道理。後面闡述我對Java Web開發的理解和(hé)構想。

2. Web開發框架層次概述

從上到下(xià)，Web開發框架的層次如(rú)下(xià)：

(1) HTML, JavaScript, CSS等頁面資(zī)源。

(2) 頁面模闆層。

如(rú)JSP, Freemarker, Velocity, XSL，fastm等。用來生成HTML, JavaScript, CSS等頁面資(zī)源。

(3) Web框架。把HTTP Request調度分派到對應的Service Entry。

(4) Business Logic.

(5) O/R Mapping.

(6) JDBC

(7) DB

根據我的經驗，一個(gè)典型的Web應用中(zhōng)的代碼比例如(rú)下(xià)：

頁面邏輯約占 50%，商(shāng)業(yè)邏輯約占30%, O/R 約占20%。

但事實上，頁面卻是最不受重視的部分，從來都被認為是髒活，累活，雜活。典型的開發過程通(tōng)常是這樣：

頁面設計人員迅速的用Dreamweaver等生成一堆文(wén)本雜亂無章的頁面，然後交給JSP程序員加入更加雜亂無章的Java代碼和(hé)Taglib。

當頁面布局風格需要改變的時候，頁面設計人員用Dreamweaver等生成一堆新的頁面。JSP程序員再重新加入更加雜亂無章的Java代碼Taglib。

至于頁面中(zhōng)的腳本邏輯調試，更是一門精深的工夫了。

根據社會規則，通(tōng)常來說，工作内容越輕松，收入越高；工作内容越髒月(yuè)累，收入越低；Web開發也是如(rú)此：做着最髒最累的活的頁面程序員，工資(zī)一般比不上後台業(yè)務邏輯程序員。

開發框架通(tōng)常會帶來這樣的結果：讓簡單的東西，變得更簡單；讓複雜的東西，變得更複雜。

這其中(zhōng)的原因在于：

一般來說，一個(gè)應用中(zhōng)簡單重複的東西占80%，複雜特殊的東西占20%。

簡單重複的東西很容易摸清規律，進行包裝，通(tōng)用化。但是，在包裝的同時，經常就阻擋住了底層的一些靈活強大的控制能力。在複雜特殊的需求中(zhōng)，确實又需要這些底層控制能力，那麼為了繞開框架的限制，付出的努力要比不用框架大得多。

打個(gè)比方，一個(gè)比較極端的例子(zǐ)。編譯語言比彙編語言的開發效率高很多，但是卻無法直接操作寄存器(qì)。當需要在編譯語言中(zhōng)操作寄存器(qì)的時候，就非常的痛苦。比如(rú)Java，也許需要JNI，寫C代碼，還要在C代碼裡面嵌入彙編。編譯、連接都很麻煩。

所以，一個(gè)框架的開發效率，就在于這個(gè)80%簡單與 20%複雜之間的平衡。

假如(rú)，不用框架來開發，簡單的80%要消耗 80個(gè)資(zī)源數，複雜的20%要消耗20個(gè)資(zī)源數，總資(zī)源數是100；使用了某個(gè)框架，簡單的80%隻要消耗10個(gè)資(zī)源數，複雜的20%要消耗40個(gè)資(zī)源數，總資(zī)源數是50。那麼，我們說，這個(gè)開發框架是有效率的。