5．可配置、可编程、可热部署、脚本逻辑 vs XML Tag逻辑
由于Java是编译语言，人们通常把变化的参数部分抽取出来，放到配置文件中。
这些配置文件通常是XML文件。这很好，没什么问题。XML很适合用来表达数据结构。
但是，对于某一种技术的狂热，通常引起对这种技术的过度使用，或者误用。
人们开始觉得，XML能够表达一切东西，包括for, if, else等逻辑。这方面的典型例子有 Workflow XML Definition，Logic TagLib, XSL Logic Tag等。
这点我不敢苟同。我的看法是，XML不适合表达逻辑，XML表达逻辑非常蹩脚。XML表达逻辑相当于自定义一门XML格式的脚本语言。
比如，Logic Tablib，很难自然的支持 if else, switch。只能蹩脚地支持一堆 <logic:if> <logic:ifNot> <logic:exists> <logic:notExists> <logic:ifNull> <logic:notNull>。
（注，好久没有接触过Taglib了。这些Tag Name都是凭以前的使用印象写的，也许名字不对，但表达这些意思的TagLib都还是有的）
如果要表达if () else if() else 就更蹩脚了。要进行非常麻烦的嵌套。
再比如，XSL 支持if, else 也非常蹩脚。非要多出来一个层次才行。
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
… else …
</xsl:otherwise>
</xsl:choose>
同样，如果要表达if () else if() else 就更蹩脚了。
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
… else …
</xsl:otherwise>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
可以看到，XML Tag 表达逻辑，非常麻烦，可读性很差，完全是一种误用，没有半点优势。当然，逻辑简单的情况下，还是可以接受的。
有人会说：XML表达逻辑，可以免编译阿。
那么我说：语法检查呢，跟踪调试呢？
对方说：只是一些简单的逻辑，不需要语法检查、跟踪调试。
我说：如果只是为了免编译，前面列出的那么多的解释执行的脚本语言更适合。XML表达的逻辑，比Java等编译语言还要麻烦很多，而脚本语言比Java等编译语言简洁多了，可读性非常好，而且脚本语言和Java语言有很好的交互性，可以相互调用。重用、结构方面都具有优势。
有人会举出Spring IoC为例子，说：你看，Spring IoC的配置文件不都是XML格式吗？
我说：
(1) Spring IoC的配置文件基本都是属性设置，Bean ID声明。没有逻辑。
(2) 我也不是很赞同Spring IoC在XML配置文件里面引用Java类的做法。这方面，其它的容器如 Pico, Nano都支持多种配置方式，其中包括了不少脚本方式。我觉得，在脚本里面定义生成Java Object，比在XML中要好。当然，Web.xml里面也引用了Java Class名字。但那是非常简单的情况。没有嵌套引用、属性赋值、构造参数等复杂的定义方式。XML适合描述一些通用的资源、数据、结构。比如，HTML, XUL, XAML，RSS就是XML用的恰当的例子。
所以，我的基本观点是这样。
(1) 纯数据，不用说，应该定义在XML中。
(2) 如果是系统中一些Java Object要用到的基本属性。比如，连接池大小等。定义在properties, XML, Script中都可以。如果定义中没有出现具体的Java Class名，倾向于定义在properties, XML文件中。如果出现了具体的Java Class名，倾向于定义在Script中。这个界限不那么明显，两者皆可。
(3) 复杂结构的Java Bean的构造生成，那是肯定会出现具体的Java Class名，应该定义在Script中。
关于“可配置 vs 可编程”，有一点要明确：只要是可编程的，一定是可配置的。但如果是可配置的，却不一定是可编程的。
这里的可编程，是指框架给程序员提供了API；可配置，是指框架给程序员提供了配置文件的格式写法。
“可编程”一定是“可配置”的。
(1) 用户至少可以自己定义配置文件，读取参数，调用API。
(2) 有那么多的解释脚本可以直接和Java互操作，完全可以直接用来当作配置文件，定义参数。
“可配置” 却不一定“可编程”的。
如果框架只给你提供了配置方式，而没有API，那意味着，你只能进行参数的静态配置。很难在动态期间改变这些参数了。你总不能尝试着用代码去改变配置文件的内容吧？即使你改动了，如果框架不进行文件的时间戳检查，就是一开始装载进来，就不再检查更改了，你不就一点办法都没有了吗？
比如，Struts Tiles的XML定义，你只能静态配置，你想在运行期间改变布局，没有办法。Site Mesh也是如此。而我们可以在运行期间任意操作XML DOM Node，别说布局了，任何东西都可以改变。
所以，一个框架首要注重的是提供API，而不是提供配置方式。这是一个重要的原则。
讨论完了“可编程”、“可配置”问题，我们来看“热部署”问题。
XML配置文件、脚本文件支持“热部署”当然要比编译语言程序的热部署容易得多。只要解释执行前，检查一下时间戳就可以了。要注意的问题，只是做好测试，因为没有编译期的语法检查。
不过，Java程序也是可以“热部署”的。只是稍微麻烦一点。典型的例子是JSP, EJB Jar等。JSP修改之后，会自动编译执行；EJB Jar丢到EJB Container里面，会被检测到并装载到JNDI命名空间。
编译语言Java程序的热部署的一个可能的技术难点是，Class或者Jar已经存在，如何监测到Class或者Jar的更改，并装载这个新版本，替换旧版本。
这个问题我具体没有研究过。从道理上讲，应该在Class Loader上下功夫。如果需要，可以参阅开源EJB Container的相关实现部分。Java还有一种“Hot Swap”技术，专门解决这个问题，可以搜索查阅一下。
这段小插曲，就到这里。下面讨论Web框架。
发表于 @ 2005年05月31日 08:28:00|评论(loading...)|编辑