XML曾經(jīng)很火,什么技術(shù)只要跟XML沾邊兒就頂上“標(biāo)準(zhǔn)”的光環(huán),后來(lái)大家慢慢意識(shí)到XML的種種弊端,比如差勁的表達(dá)能力,枯燥的解析(SAX),性能低下(DOM),越來(lái)越多的人開(kāi)始理智地使用XML。只把它用在“合適”的時(shí)候。程序員中仍然存在濫用XML的慣性,最近還和同事們爭(zhēng)論了半天java和xml的使用場(chǎng)景。
先跑下題聊聊java. 近兩年越來(lái)越多搞Java的人跑去學(xué)動(dòng)態(tài)語(yǔ)言,ruby, groovy, scala之類的。 原因在于這些動(dòng)態(tài)語(yǔ)言“表達(dá)能力”更好。是的,這些語(yǔ)言更靈活,更精煉。不難理解,后出的編程語(yǔ)言更傾向于合理,畢竟它有前人的寶貴經(jīng)驗(yàn)可以借鑒。java的一些設(shè)計(jì)的確令人詬病,比如checked exception, 對(duì)泛型支持的不完備。但就從“表達(dá)力”來(lái)說(shuō),我覺(jué)得java的表達(dá)力不強(qiáng)不弱正正好好。Java的定位本來(lái)就是大規(guī)模企業(yè)級(jí)應(yīng)用,過(guò)度靈活的編程語(yǔ)言不易維護(hù)。新型的動(dòng)態(tài)語(yǔ)言傾向于過(guò)度靈活,雖然支持快速開(kāi)發(fā),但是我相信在多人,甚至幾十人合作開(kāi)發(fā)的項(xiàng)目中,如果對(duì)語(yǔ)言非常靈活的特性不加以限制,隨著程序的規(guī)模一點(diǎn)點(diǎn)增大,維護(hù)的難度會(huì)陡然加大。而一旦通過(guò)convention限制使用語(yǔ)言的一些特性,限制來(lái)限制去不就又成java了么?好吧,好吧,我知道這會(huì)是個(gè)有爭(zhēng)議的話題,我就是不相信用ruby能做個(gè)ERP出來(lái),五年之后也不會(huì)有。這不是這篇文字要討論的重點(diǎn),我想說(shuō)的是,java在表達(dá)能力方面已經(jīng)讓一些人不滿意了,而XML呢?XML的表達(dá)能力比java差了N多個(gè)數(shù)量級(jí)!這年頭,騎三輪車回收電腦的都知道程序設(shè)計(jì)要有彈性,換句話說(shuō),能適應(yīng)變化。于是一個(gè)簡(jiǎn)單的夢(mèng)想就是,來(lái)了新需求,咱不用改code, 改改xml配置就能滿足就好了。是的,我也這么希望,尤其在我睡著的時(shí)候。以Java這樣的面向?qū)ο?+ 一些動(dòng)態(tài)特性(reflection,dynamic proxy甚至aspectJ)的語(yǔ)言都很難做到如此靈活的應(yīng)對(duì)變化,xml怎么會(huì)更容易做到呢?很多人喜歡XML的簡(jiǎn)單直觀。比如我們可以在SWING上面封裝一層基于XML的界面引擎,于是GUI就可以簡(jiǎn)單地寫(xiě)成這種風(fēng)格:
1: <panel id=”xyz” width=”360” heigh=”720”……>
2:
3: <label id=”label_1” attr_1=”xxx” attr_2=”yyy”/>
4:
5: <textarea id=”textarea_1” attr_1=”xxx” attr_2=”yyy”/>
6:
7: </panel>
它有一個(gè)好處就是易于擴(kuò)展,比如現(xiàn)在又想加一個(gè)checked box,只要在里面插入一個(gè)<checkbox id=……/>就行了。我承認(rèn)它的確易于擴(kuò)展。但是如果你簡(jiǎn)單封裝一下java API,不也是一行code的事兒么?無(wú)非就是panel.addChild(new CheckedBox(attr_1, attr_2))之類的這么一句code。難道這就不簡(jiǎn)單,不直觀了?程序一涉及到xml,就涉及到IO, 解析XML,這都是額外的工作量,況且xml中的“對(duì)象”(我很難承認(rèn)complex type算是對(duì)象)跟Java里的對(duì)象根本不是一碼事,從xml里解析出來(lái)的表示數(shù)據(jù)類型的type最后還是要生成對(duì)應(yīng)特定的java對(duì)象,這都是麻煩事兒。 多寫(xiě)code的壞處遠(yuǎn)不止寫(xiě)的時(shí)候費(fèi)事兒,所寫(xiě)的每行code最后都是要維護(hù)的,就算code很strong, 我還嫌code太長(zhǎng),滾鼠標(biāo)滾輪兒累手指頭,多個(gè)文件放那兒累花眼。總之,但凡xml改一兩行能解決的問(wèn)題,不用xml,就用java也是一兩行的工作量,只要稍微花點(diǎn)心思封裝好API就行。不用XML可以省不少開(kāi)發(fā)和維護(hù)的工作。理想情況下,改改xml就能應(yīng)對(duì)新需求。但現(xiàn)實(shí)和理想總是有差距的,一旦xml的schema不足以應(yīng)對(duì)變化,我們就得改xml, 改schema,改解析的code,改業(yè)務(wù)邏輯的code(這個(gè)沒(méi)法避免)。這不是沒(méi)事兒找病么?xml是extendable markup language. 它真能比java還extendable?扯淡!
當(dāng)然XML有它合理的應(yīng)用場(chǎng)景,我能想到的是四個(gè)方面,一定有漏掉的情況,歡迎朋友們補(bǔ)充。
一, 存儲(chǔ)樹(shù)狀數(shù)據(jù)(起碼三層以上。三層或三層以下就用java合成也挺方便的);二, 配置信息;三、描述標(biāo)準(zhǔn)協(xié)議(比如wsdl); 四,wrap數(shù)據(jù)以便于傳輸?shù)?比如soap)
在應(yīng)用產(chǎn)品中,自己設(shè)計(jì)xml來(lái)輔助應(yīng)用系統(tǒng)的場(chǎng)景不應(yīng)該很多。
另有一種使用xml的誤區(qū)是,把xml暴露給用戶讓他自己“擴(kuò)展”。我覺(jué)得, 凡是暴露給客戶的東西都是UI,平時(shí)Swing界面,web界面是GUI,暴露給客戶改的xml算是UI. 也許有的人說(shuō),一旦弄GUI,就有一堆麻煩事兒,比如i18n啥的,讓用戶自己配置配置xml就能改動(dòng)頁(yè)面不是挺好么,還不用考慮i18n了。問(wèn)題是,用xml不是“不用”考慮國(guó)際化,而是根本沒(méi)法考慮國(guó)際化。
<wallet><money>100</money></wallet> 這個(gè)美國(guó)人能看懂,對(duì)中國(guó)人就得用<錢(qián)包><錢(qián)>100</錢(qián)></錢(qián)包>
這么做很明顯用戶體驗(yàn)很差。另外,這也一定程度上暴露了你的實(shí)現(xiàn)方式,起碼客戶知道,哦,原來(lái)你是用xml存數(shù)據(jù)的,schema就是這個(gè)樣子。
Ajax剛鋪天蓋地的時(shí)候,都用xml傳數(shù)據(jù),后來(lái)越來(lái)越多人用Json. Spring和Hibernate等一堆框架在幾年前都用巨大的XML來(lái)配置,現(xiàn)在越來(lái)越多人轉(zhuǎn)向annotation(當(dāng)然,這個(gè)有一定爭(zhēng)議)。XML熱度減退,大家趨于理性是好事。XML當(dāng)然很有用,但是程序員們?cè)撃芟肭宄裁词?使用", 什么是"濫用".