人在江湖

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  82 Posts :: 10 Stories :: 169 Comments :: 0 Trackbacks

XML曾经很火,什么技术只要跟XML沾边儿就顶上“标准”的光环,后来大家慢慢意识到XML的种种弊端,比如差劲的表达能力,枯燥的解析(SAX),性能低下(DOM),越来越多的人开始理智地使用XML。只把它用在“合适”的时候。程序员中仍然存在滥用XML的惯性,最近还和同事们争论了半天java和xml的使用场景。

先跑下题聊聊java. 近两年越来越多搞Java的人跑去学动态语言,ruby, groovy, scala之类的。 原因在于这些动态语言“表达能力”更好。是的,这些语言更灵活,更精炼。不难理解,后出的编程语言更倾向于合理,毕竟它有前人的宝贵经验可以借鉴。java的一些设计的确令人诟病,比如checked exception, 对泛型支持的不完备。但就从“表达力”来说,我觉得java的表达力不强不弱正正好好。Java的定位本来就是大规模企业级应用,过度灵活的编程语言不易维护。新型的动态语言倾向于过度灵活,虽然支持快速开发,但是我相信在多人,甚至几十人合作开发的项目中,如果对语言非常灵活的特性不加以限制,随着程序的规模一点点增大,维护的难度会陡然加大。而一旦通过convention限制使用语言的一些特性,限制来限制去不就又成java了么?好吧,好吧,我知道这会是个有争议的话题,我就是不相信用ruby能做个ERP出来,五年之后也不会有。这不是这篇文字要讨论的重点,我想说的是,java在表达能力方面已经让一些人不满意了,而XML呢?XML的表达能力比java差了N多个数量级!这年头,骑三轮车回收电脑的都知道程序设计要有弹性,换句话说,能适应变化。于是一个简单的梦想就是,来了新需求,咱不用改code, 改改xml配置就能满足就好了。是的,我也这么希望,尤其在我睡着的时候。以Java这样的面向对象 + 一些动态特性(reflection,dynamic proxy甚至aspectJ)的语言都很难做到如此灵活的应对变化,xml怎么会更容易做到呢?很多人喜欢XML的简单直观。比如我们可以在SWING上面封装一层基于XML的界面引擎,于是GUI就可以简单地写成这种风格:

   1: <panel id=”xyzwidth=”360heigh=”720”……>
   2:  
   3: <label id=”label_1attr_1=”xxxattr_2=”yyy/>
   4:  
   5: <textarea id=”textarea_1attr_1=”xxxattr_2=”yyy/>
   6:  
   7: </panel>

它有一个好处就是易于扩展,比如现在又想加一个checked box,只要在里面插入一个<checkbox id=……/>就行了。我承认它的确易于扩展。但是如果你简单封装一下java API,不也是一行code的事儿么?无非就是panel.addChild(new CheckedBox(attr_1, attr_2))之类的这么一句code。难道这就不简单,不直观了?程序一涉及到xml,就涉及到IO, 解析XML,这都是额外的工作量,况且xml中的“对象”(我很难承认complex type算是对象)跟Java里的对象根本不是一码事,从xml里解析出来的表示数据类型的type最后还是要生成对应特定的java对象,这都是麻烦事儿。 多写code的坏处远不止写的时候费事儿,所写的每行code最后都是要维护的,就算code很strong, 我还嫌code太长,滚鼠标滚轮儿累手指头,多个文件放那儿累花眼。总之,但凡xml改一两行能解决的问题,不用xml,就用java也是一两行的工作量,只要稍微花点心思封装好API就行。不用XML可以省不少开发和维护的工作。理想情况下,改改xml就能应对新需求。但现实和理想总是有差距的,一旦xml的schema不足以应对变化,我们就得改xml, 改schema,改解析的code,改业务逻辑的code(这个没法避免)。这不是没事儿找病么?xml是extendable markup language. 它真能比java还extendable?扯淡!

当然XML有它合理的应用场景,我能想到的是四个方面,一定有漏掉的情况,欢迎朋友们补充。

一, 存储树状数据(起码三层以上。三层或三层以下就用java合成也挺方便的);二, 配置信息;三、描述标准协议(比如wsdl); 四,wrap数据以便于传输等(比如soap)

在应用产品中,自己设计xml来辅助应用系统的场景不应该很多。

另有一种使用xml的误区是,把xml暴露给用户让他自己“扩展”。我觉得, 凡是暴露给客户的东西都是UI,平时Swing界面,web界面是GUI,暴露给客户改的xml算是UI. 也许有的人说,一旦弄GUI,就有一堆麻烦事儿,比如i18n啥的,让用户自己配置配置xml就能改动页面不是挺好么,还不用考虑i18n了。问题是,用xml不是“不用”考虑国际化,而是根本没法考虑国际化。

<wallet><money>100</money></wallet> 这个美国人能看懂,对中国人就得用<钱包><钱>100</钱></钱包>

这么做很明显用户体验很差。另外,这也一定程度上暴露了你的实现方式,起码客户知道,哦,原来你是用xml存数据的,schema就是这个样子。

Ajax刚铺天盖地的时候,都用xml传数据,后来越来越多人用Json. Spring和Hibernate等一堆框架在几年前都用巨大的XML来配置,现在越来越多人转向annotation(当然,这个有一定争议)。XML热度减退,大家趋于理性是好事。XML当然很有用,但是程序员们该能想清楚什么是"使用", 什么是"滥用".

posted on 2011-05-07 00:22 人在江湖 阅读(2902) 评论(9)  编辑  收藏 所属分类: design

Feedback

# re: XML的滥用 2011-05-07 12:46 Unmi
好像还是没理出个理来,没看到强有力的证明。  回复  更多评论
  

# re: XML的滥用 2011-05-07 18:18 rox
和楼主感同身受。
XML不是不好,是被神话和滥用了。
XML使用上,最方便的莫过于Flex的ActionScript,太方便了。  回复  更多评论
  

# re: XML的滥用 2011-05-10 06:36 jacklondon
有几点不同意楼主:
1. xml 在 GUI 编程中的应用。
我觉得还算正常。纯 Java 之所以不适合,是因为对同样的工作,Java 可以有多种写法,会造成所见即所得的显示问题。以下摘自我之前的博客:
Java 语法中并没有支持 GUI design time 的语法标签,对于编译器来说,在设计时从Java 代码还原到设计窗口技术上太难。 JBuilder 允许程序员修改向导产生的 jbInit 函数,结果是 JBuilder 的 GUI design 经常出笑话,比如 JBuilder 好几个版本都存在的 GUI 设计时只认识 this.setSize 不认识 this.setBounds 的问题。 Netbeans 干脆不允许程序员修改 initComponents 函数,是好是坏还不一定。一般而言,Netbeans 对于每一个可视化的 .java 文件都会生成一个 .form 文件。对于 Netbeans 编译器来说,在设计时从Java 代码还原到设计窗口是通过解析 .form 文件,这样技术难度下降很多,也不会像 JBuilder 一样经常出低级笑话。
免费的 Java GUI 开发工具 Netbeans 介绍
http://blog.csdn.net/jacklondon/archive/2003/04/19/14262.aspx
2. 国际化用 xml 很正常。之前很多程序都有 ini 文件,这样做国际化,好处在于可以让热心的用户(不懂编程的用户)帮忙翻译。楼主所说“一定程度上暴露了你的实现方式”没有什么道理。我用 ini /xml 暴露了什么?
----欢迎大家试用我们的单点登录系统 http://zhegui.biz  回复  更多评论
  

# re: XML的滥用 2011-05-10 08:01 人在江湖
Jacklondon, 你举的两个例子跟我的想法没有冲突。
第一个例子:
你说XML可以在GUI里使用,是基于特定的IDE的支持,<B>不是你自己设计出一个基于xml的引擎</B>。NetBeans这么做是因为它是IDE。我绝不相信哪个应用产品先基于Swing封装出来一套xml引擎,然后让developer写xml, 而不用写java, 那使用这套引擎的人就根本不必是java developer了。 所谓"GUI Design出笑话"是IDE的问题,不是swing的问题。design time form文件应该是生成出来的吧?不是自己手敲xml就生成class, 让JDK解析的吧?我认为有强烈需求要求程序员用xml写GUI背后的原因是程序员本身不是swing developer.基于swing封装成客户化的更方便的component(更方便的意思就是更不灵活),一定比封装成xml引擎更简单.
第二个例子,国际化不是functional层面的,“热心的用户”是帮程序员做事情的,不是真正产品的consumer. 我不喜欢的是,强迫使用产品的用户edit xml.  回复  更多评论
  

# re: XML的滥用 2011-05-11 00:08 jacklondon
@人在江湖
所谓"GUI Design出笑话"是IDE的问题,不是swing的问题----第一,没有人提到Swing;第二,如果所有 Java IDE 都无法解决这些问题,就说明 Java 语法不适合用于“用户界面设计”。注意,这里谈的是“设计时”问题,不是“运行时”问题。
如果说国际化用 xml/ini 是强迫用户 edit xml ,那么你用什么技术谈得上算是不强迫?如果按微软的风格,是要用资源dll 的,这更强迫翻译人员非用 visual studio 不可,更不可取。至少国际化用 xml/ini,是可以让别人用操作系统自带工具(windows/linux 都可带有可修改 xml/ini 的文本编辑器),不用另外找工具。  回复  更多评论
  

# re: XML的滥用 2011-05-11 07:43 人在江湖
@jacklondon
哈哈,首先还是感谢你在我的博客里发表技术看法,喜欢看到有见地的想法。
我们没有在讨论同一个问题,你说“设计时”,只有IDE才涉及到“设计时”的问题,我博客里举的例子是说程序员"手敲XML"还是"手敲java"写应用程序的界面。我觉得从易用性角度说,两者没区别,但封装到“手敲XML”的成本要高出很多很多,所以根本不可取。
至于国际化的问题....
我举的例子是功能性的,不是i18n的,所以这个例子是
<wallet><money>100</money></wallet> 这个美国人能看懂,对中国人就得用<钱包><钱>100</钱></钱包>

用户修改xml来做国际化,修改的是content,不是标签本身。把resource property放xml里我觉得没有问题,那么样子会是
<key name="abc.txt"> wallet </key>
<key name="abc.txt"> 钱包 </key>
我没说非得把key翻译成 钥匙。 因为i18n用途的xml结构比辅助功能的xml简单得多,对于复杂的xml结构(功能性质的),<B>标签本身是有含义的,所以标签本身有i18n的必要</B>。你跟我说的不是一回事。尽管我觉得用properties文件够用了,不知道为什么一定要用xml. 对比java, 一涉及到xml就要多考虑I/O和解析。对比properties文件,一涉及到xml就要格外考虑解析。  回复  更多评论
  

# re: XML的滥用 2011-05-18 15:34 greatghoul
我是不喜欢使用xml的,感觉写起来很累,还是annotation好用些

相比之下,yaml要比xml好用多了。  回复  更多评论
  

# re: XML的滥用 2011-05-19 00:23 jacklondon
1. 在应用产品中,自己设计xml来辅助应用系统的场景不应该很多===楼主没有说出个道道来。
2. 用 xml不是“不用”考虑国际化,而是根本没法考虑国际化====没有任何道理。用 ini/xml 做多语言的软件多了,我现在在用的 notepad++ 好像就是,dreamweaver 也是。
3. 起码客户知道,哦,原来你是用xml存数据的,schema就是这个样子。====那有如何?你知道又如何?你认为把软件做到别人看不明白才是水平?软件好用、符合用户要求才是水平。  回复  更多评论
  

# re: XML的滥用[未登录] 2011-05-19 17:52 Frank
xml 是可以国际化的,可以看
Best Practices for XML Internationalization
http://www.w3.org/TR/xml-i18n-bp/

就是太麻烦了, Best Practice 就有24条之多,看起来那是相当的崩溃

xml 处理起来比较麻烦, 尤其在没有好的engine, 自己 parse 那是相当的痛苦,要是暴露给客户,那就更麻烦了  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: