【正文】 目的不同的東西整合起來，才能搭建出一個(gè)整體的系統(tǒng)。與C/S開發(fā)的一種語言包打天下不同，B/S系統(tǒng)的開發(fā)需要在多個(gè)層次上進(jìn)行編程開發(fā)：瀏覽器中，用HTML和JavaScript編程；應(yīng)用服務(wù)器上，數(shù)據(jù)庫服務(wù)器上用SQL語句編程。在應(yīng)用系統(tǒng)中，大量的頁面是動(dòng)態(tài)，而非靜態(tài)頁面，因此必須在應(yīng)用服務(wù)器上完成動(dòng)態(tài)頁面到靜態(tài)HTML的轉(zhuǎn)換工作。在B/S系統(tǒng)中，用戶通過客戶機(jī)上的瀏覽器來訪問后臺(tái)的Web服務(wù)器，Web服務(wù)器再把相應(yīng)的請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器來處理，應(yīng)用服務(wù)器再將其中的數(shù)據(jù)訪問請(qǐng)求轉(zhuǎn)發(fā)給數(shù)據(jù)庫服務(wù)器進(jìn)行處理。這種開發(fā)環(huán)境下可以使用圖形化的控件來搭建用戶界面，用戶的交互性比較好。Web應(yīng)用系統(tǒng)的開發(fā)，就像一座大山一樣，把所有的人，無論是甲方還是乙方，無論是開發(fā)人員，維護(hù)人員還是系統(tǒng)用戶，都被累垮了。本文先從Web開發(fā)的現(xiàn)狀困境開始，分析造成目前困境的原因，然后通過回顧B/S技術(shù)架構(gòu)的演化，以及對(duì)比C/S和B/S的開發(fā)模式的差異，提出一套新的開發(fā)解決思路，最后介紹WebDW系列產(chǎn)品的設(shè)計(jì)目的和簡(jiǎn)單功能，再以此為基礎(chǔ)來進(jìn)行擴(kuò)展討論。雖然J2EE已經(jīng)非常普及，但從技術(shù)上來講，它本身還是存在很多缺陷的，比較突出的缺點(diǎn)，就是開發(fā)效率低，維護(hù)更加復(fù)雜，許多項(xiàng)目組都陷入其中不可自拔。雖然它并未完全兌現(xiàn)剛剛出現(xiàn)時(shí)的種種美好許諾，跨平臺(tái)，分布式，易于開發(fā)維護(hù)等等，但J2EE的廣泛普及，已經(jīng)是一個(gè)不爭(zhēng)的事實(shí)。討論的技術(shù)方向，主要針對(duì)J2EE，其余技術(shù)方向不作為重點(diǎn)討論，僅供參考。但B/S架構(gòu)本身，要比C/S復(fù)雜的多，加上新技術(shù)層出不窮，整個(gè)行業(yè)都處于巨大的困境之中。一般在這種架構(gòu)中，服務(wù)器是一個(gè)數(shù)據(jù)庫服務(wù)器，只負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取訪問支持；前臺(tái)程序采用 VB，PB，Delphi 等圖形開發(fā)工具來開發(fā)，通過網(wǎng)絡(luò)直接連接到后臺(tái)的數(shù)據(jù)庫服務(wù)器，通過發(fā)送SQL 命令來實(shí)現(xiàn)數(shù)據(jù)庫的訪問。如下圖。首先，客戶機(jī)上只有一個(gè)通用的瀏覽器，用戶操作界面是通過Web服務(wù)器返回的HTML語言來進(jìn)行描述的，如果需要一些動(dòng)態(tài)特征，則不得不通過在HTML頁面中嵌入JavaScript來實(shí)現(xiàn)。假如請(qǐng)求是一個(gè)jsp頁面，應(yīng)用服務(wù)器首先讀取這個(gè)文件，然后把它翻譯成一個(gè)java文件，再編譯成一個(gè)class文件，再解釋執(zhí)行這個(gè)class文件，如果需要再訪問后臺(tái)數(shù)據(jù)庫，最后產(chǎn)生一個(gè)HTML格式的輸出文件流，返回給Web服務(wù)器，再返回給客戶機(jī)瀏覽器解釋成一個(gè)界面。結(jié)果在試圖解決問題的同時(shí)，這些產(chǎn)品本身又造成了新的問題。在B/S系統(tǒng)的開發(fā)中，開發(fā)人員是最辛苦的一類人。另外一個(gè)頭疼的事情，就是技術(shù)架構(gòu)的變化性，今天一個(gè)語言，明天一個(gè)語言，一旦底層的平臺(tái)變了，自己費(fèi)勁力氣學(xué)會(huì)的東西就一文不值了，年齡一天一天大了，那里有那么多的精力老追趕新技術(shù)呢，于是很多人轉(zhuǎn)行離開了。時(shí)間和精力被無謂的消耗掉了。終于，在多次延期，多次修改，無數(shù)次補(bǔ)丁以后，系統(tǒng)終于上線了。如果是開發(fā)人員自己來做維護(hù)，相對(duì)還好一點(diǎn)，至少里面是怎么回事情，大概知道個(gè)差不多，有了問題，小修小補(bǔ)打打補(bǔ)丁，雖然累點(diǎn)，總還是有希望的；如果不是自己開發(fā)的，要來做維護(hù)，那就要了老命了，要文檔沒文檔，要注釋沒注釋，還要面對(duì)同樣多的技術(shù)架構(gòu)，語言和技術(shù)平臺(tái)，用維護(hù)人員的話說，就是如履薄冰，如臨深淵，每天都在祈禱，這個(gè)系統(tǒng)別出問題。當(dāng)維護(hù)人員覺得系統(tǒng)已經(jīng)無法支持下去時(shí)，他們會(huì)一走了之。不幸的是，新的系統(tǒng)一般來說會(huì)重復(fù)舊系統(tǒng)已經(jīng)走過的路線，開發(fā)的更加復(fù)雜，更加難以維護(hù)，最后再次陷入無法維護(hù)的境界。CPU不是誰都能設(shè)計(jì)的，所以Intel發(fā)了；OS不是誰都能開發(fā)的，所以MS發(fā)了。最大的好處，是提供這種復(fù)雜性的基礎(chǔ)設(shè)備的公司，例如Oracle, BEA, SUN, HP這些。這就是基礎(chǔ)設(shè)備提供商的生命所在，不斷增加系統(tǒng)的復(fù)雜性。對(duì)于公司來講，人力成本居高不下，所有人員被困在一個(gè)個(gè)項(xiàng)目中掙扎，公司永遠(yuǎn)長(zhǎng)不大，變不強(qiáng)。在一個(gè)復(fù)雜度無法控制的狀態(tài)下，公司只能是疲于奔命，隨波逐流。所有的招標(biāo)文件中，一律指出要保證技術(shù)的先進(jìn)性，素不知，所謂的先進(jìn)性，往往也意味著新技術(shù)，對(duì)于整個(gè)系統(tǒng)而言，往往是增加其復(fù)雜性，而不是減少其復(fù)雜性。在按人頭計(jì)算費(fèi)用的模式下，開發(fā)公司傾向于增加人手來提高整個(gè)項(xiàng)目的費(fèi)用計(jì)算，而且最好是增加低成本的新手來做項(xiàng)目，這樣做的結(jié)果就是整個(gè)項(xiàng)目陷入盲目運(yùn)行的狀態(tài)，所有的人都在忙，但不知道在忙啥，整體作的是無用功。項(xiàng)目的過程管理，時(shí)間管理這些都先不談，單獨(dú)談?wù)勴?xiàng)目的復(fù)雜性對(duì)甲方的長(zhǎng)遠(yuǎn)影響。而甲方的科技部門要同時(shí)維護(hù)這樣并行的多個(gè)系統(tǒng)，再考慮各個(gè)系統(tǒng)之間的交互關(guān)系，最后的結(jié)果就是焦頭爛額，忙得不可開交。有的甲方是家大業(yè)大，浪費(fèi)點(diǎn)沒啥，他們可能不太在乎系統(tǒng)建設(shè)時(shí)浪費(fèi)的一點(diǎn)點(diǎn)資金，但對(duì)于系統(tǒng)運(yùn)行帶來的煩惱也是無可奈何。順便說一下前幾年的ERP熱，以后隨后對(duì)ERP的全面質(zhì)疑。如果壓力過大的話，甲方就會(huì)發(fā)現(xiàn)，自己本來是一個(gè)業(yè)務(wù)性的公司，最后卻不明不白變成了一個(gè)IT相關(guān)的公司，信息部門最后變成了尾大不掉的一個(gè)部門。雖然在《人月神話》中，布魯克斯已經(jīng)指出：軟件的復(fù)雜性是它的本質(zhì)特性之一，但在實(shí)際工作中，人們往往容易忘記這一點(diǎn)。這些產(chǎn)品本身都是相對(duì)獨(dú)立的，都構(gòu)成一個(gè)自己的知識(shí)體系，而要把這些不同范疇的技術(shù)整合起來，使之成為一個(gè)統(tǒng)一的整體，光在技術(shù)層次上，就構(gòu)成了一個(gè)非常復(fù)雜的系統(tǒng)。在傳統(tǒng)的J2EE框架內(nèi)，應(yīng)用開發(fā)已經(jīng)太過復(fù)雜，變得臃腫龐大，這一點(diǎn)業(yè)內(nèi)已有定論。3 Web應(yīng)用以誰為中心？瀏覽器？服務(wù)器？企業(yè)Web應(yīng)用，指的是企業(yè)內(nèi)部使用B/S架構(gòu)搭建的企業(yè)信息系統(tǒng)，用戶一般局限在企業(yè)內(nèi)部，為了適應(yīng)企業(yè)某個(gè)業(yè)務(wù)流程而設(shè)計(jì)開發(fā)使用的系統(tǒng)。本文主要討論以J2ee架構(gòu)為基礎(chǔ)的Web應(yīng)用，其他架構(gòu)的暫不討論。當(dāng)時(shí)的計(jì)算模式，是完全基于后臺(tái)服務(wù)器的計(jì)算。Flex/SL/ExtJs各行其道服務(wù)器端處于停滯狀態(tài)，JSF曇花一現(xiàn)后臺(tái)的問題已經(jīng)基本解決，現(xiàn)在關(guān)注的重點(diǎn)又轉(zhuǎn)向前臺(tái)，解決用戶界面和友好性問題。字符終端/啞終端/主機(jī) 時(shí)代Unix圖形化終端/客戶機(jī)/服務(wù)器 時(shí)代Apple, DOS,Windows,Oracle啞瀏覽器時(shí)代Netscape/ ApacheApplet時(shí)代AppletJ2EE時(shí)代WebLogic/Websphere/JBoss后J2EE時(shí)代/開源框架時(shí)代Struts/Spring/HibernateIBMApple / MSOracle/SybaseNetScapeSun / JavaBEA/ApacheIBMRIA時(shí)代Flex / SlightLight / ExtJSAdobe / MSJavaScript核心問題在與瀏覽器和服務(wù)器的合理分工。訪問采用標(biāo)準(zhǔn)HTTP協(xié)議進(jìn)行2動(dòng)態(tài)數(shù)據(jù)訪問(數(shù)據(jù)庫讀取/存儲(chǔ))調(diào)用后臺(tái)功能接口，得到標(biāo)準(zhǔn)格式的數(shù)據(jù)包信息；并對(duì)這些數(shù)據(jù)進(jìn)行渲染提供標(biāo)準(zhǔn)訪問接口，供瀏覽器進(jìn)行調(diào)用前臺(tái)發(fā)送調(diào)用要求，后臺(tái)響應(yīng)返回結(jié)果。初級(jí)4 J2EE框架批判這一章節(jié)主要是將以前零星編寫的關(guān)于J2EE框架的一些感想集中起來，文字方面沒有進(jìn)行太多的潤(rùn)色。但如果和C/S的開發(fā)模式進(jìn)行對(duì)比就會(huì)發(fā)現(xiàn),這種強(qiáng)制性的分層,其實(shí)是人為將原來的一件事情,分成三個(gè)層次來解決,然后每個(gè)層次再加上額外的解決方案的一個(gè)解決方案. 或者說,所有這些問題,本來可以根本上就不存在,但你生生制造出這么多問題來,于是再發(fā)明一些新的方案來解決這些問題. 以前有個(gè)笑話,說某人找了個(gè)媳婦,在和面,面多了,就加水,一會(huì)兒水多了,就加面,于是乎事情越來越多. 現(xiàn)在的Java Web開發(fā),正走向這樣一條不歸路,發(fā)現(xiàn)一個(gè)問題,就發(fā)明一個(gè)新框架來解決,于是又帶來新的一個(gè)問題,于是又發(fā)明另一個(gè)框架來解決. 現(xiàn)在Java Web開發(fā)的一個(gè)怪現(xiàn)象是,程序的代碼不少,但和業(yè)務(wù)有關(guān)的沒有多少, 相反是框架相關(guān)的層出不窮. 所有這些問題的根源,我看就出在強(qiáng)制性的分層上. 界面層,業(yè)務(wù)邏輯層,數(shù)據(jù)訪問層的劃分并沒有問題,問題在于分層以后,是否一定要把他們拆分到不同的代碼段來實(shí)現(xiàn),是否一定要把這些當(dāng)成完全不同的問題來采用完全不同的藥方來解決. 既然在C/S上這三個(gè)問題可以簡(jiǎn)單來用一個(gè)語言,一個(gè)方案來解決,為啥B/S的開發(fā)一定要分開處理,搞的大家疲勞不堪呢? ,毛將焉附關(guān)于技術(shù),語言上的是是非非,實(shí)在不是一兩句話能夠說清楚的事情. 前兩天在和朋友的交流中,忽然想到這樣一句話:皮之不存,毛將焉附,以此來形容很多技術(shù)的興衰,真是非常貼切. 所有的技術(shù),語言也好,框架也好,其實(shí)都有一個(gè)基本的假設(shè),在討論問題的時(shí)候,往往是在這個(gè)隱函的前提下來討論才得出的結(jié)論,一旦經(jīng)過認(rèn)真考慮,把這個(gè)假設(shè)推翻了,那么整個(gè)技術(shù)的大廈也就轟然倒塌了. 以下舉例說明. 譬如J2EE架構(gòu),在早期推出的時(shí)候,強(qiáng)調(diào)EJB這一組件的功能,其實(shí)隱含了一個(gè)假設(shè):所有的應(yīng)用都需要分布式支持,絕大部分應(yīng)用都不真正需要分布式支持,推除了J2EE without . 譬如JSP技術(shù),按其本名,Java Server Page,就是利用Java語言在后臺(tái)服務(wù)器上,其一,頁面是動(dòng)態(tài)生成,而且是用Java動(dòng)態(tài)生成。 J2EE體系結(jié)構(gòu)提供中間層集成框架用來滿足無需太多費(fèi)用而又需要高可用性、高可靠性以及可擴(kuò)展性的應(yīng)用的需求。第二部分是如何從把這些元素組合起來形成一個(gè)統(tǒng)一的ui,第二部分屬于數(shù)據(jù)結(jié)構(gòu)的定義部分。這幾個(gè)方面的因素之間互為因果，相互作用，最后把整個(gè)開發(fā)過程拖入泥沼之中。這種分工方式在學(xué)術(shù)上也許是不錯(cuò)的范例，但在實(shí)際的項(xiàng)目開發(fā)中，嚴(yán)格的分工就必然意味著多工種，多層次的人員溝通和協(xié)調(diào)。在整個(gè)項(xiàng)目角度來看，幾乎每個(gè)人都在盲人摸象，沒有整體概念，項(xiàng)目的很多問題都被掩蓋起來，到了最后關(guān)頭才集中爆發(fā)出來。正因?yàn)榉止け粡?qiáng)化和強(qiáng)調(diào)了，不同崗位，不同角色的工作人員自然采用不同的技術(shù)路線來試圖解決問題，并逐漸發(fā)展出自己的一套技術(shù)路線出來。Spring的出現(xiàn)就是這種情況的一個(gè)很好的注解，因?yàn)殚_發(fā)中使用的東西太多了，不好配置，于是Spring的發(fā)明人想了一個(gè)辦法，把所有這些東西打了個(gè)大包，裝在一起，起了個(gè)大名叫Spring。開發(fā)的時(shí)候分工太細(xì)，使用的技術(shù)過多，最終必然導(dǎo)致開發(fā)和維護(hù)的復(fù)雜度增加，必然導(dǎo)致開發(fā)維護(hù)的成本居高不下。同時(shí)，在一個(gè)如此復(fù)雜的開發(fā)環(huán)境中，開發(fā)人員自己都無法從整體上描述開發(fā)整體過程，開發(fā)的整體結(jié)構(gòu)，在這種情況下，客戶本身更加無法介入開發(fā)的整個(gè)過程之中，而只能在程序開發(fā)完成以后再提出意見進(jìn)行修改。6解決之道要解決J2EE企業(yè)應(yīng)用開發(fā)的種種問題，就必須轉(zhuǎn)換思路，從減少分層，簡(jiǎn)化技術(shù)架構(gòu)，銷減系統(tǒng)復(fù)雜度，加強(qiáng)用戶參與這幾個(gè)方面同時(shí)努力。WebDW的設(shè)計(jì)目的，是簡(jiǎn)化Web開發(fā)流程，提高開發(fā)效率，降低開發(fā)和系統(tǒng)維護(hù)的成本。WebDW可提供源代碼銷售，您可以購買源代碼進(jìn)行改造，把WebDW的功能完全集成到您的系統(tǒng)或者平臺(tái)之中。 WebDW設(shè)計(jì)思路最基本的設(shè)計(jì)思路是：圖形化界面定義，所見即所得，直接數(shù)據(jù)庫訪問，不再層層轉(zhuǎn)發(fā)。這個(gè)思路應(yīng)該說是一個(gè)很好的思路，但不幸的是，PB中WebDW的使用存在諸多限制，無論在后臺(tái)對(duì)應(yīng)的應(yīng)用服務(wù)器（限定服務(wù)器類型），還是本地客戶機(jī)（需要安裝本地庫），都有非常不便的地方。WebDW控件和后臺(tái)數(shù)據(jù)庫的交互，通過在Web服務(wù)器上定義一個(gè)數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器來實(shí)現(xiàn)，WebDW控件直接向后臺(tái)發(fā)送SQL命令，經(jīng)轉(zhuǎn)發(fā)給后臺(tái)數(shù)據(jù)庫以后返回結(jié)果再在前臺(tái)進(jìn)行數(shù)據(jù)展現(xiàn)。目前提供ActiveX控件形式和Java控件，F(xiàn)lash格式的將在未來提供。WebDW控件，就是在Web上運(yùn)行的DataWindow組件對(duì)象。WebDW控件是應(yīng)用程序的動(dòng)態(tài)執(zhí)行部分，數(shù)據(jù)窗口對(duì)象是應(yīng)用程序的靜態(tài)定義部分。WebDW應(yīng)用程序本身也會(huì)提供數(shù)據(jù)窗口對(duì)象的繪制功能，未來會(huì)根據(jù)用戶需要逐步細(xì)化