IDC资讯中心
上次说到myappfuse要有一个代码生成工具， codegeneration.net上汇集了各种平台各种语言的工具。
其中一些用到uml做元数据的，就变成了上年最流行的mda tool。mda其实是超级炒冷饭了，偶n年前的毕业论文做的就是这个题目，现在再看进步也不大。
不过想下也正常。因为mda是由模型、实现和转换程序三者构成的，如果模型定义飞速发展了，与底层实现之间必定会形成巨大落差，需要转换程序做大量工作来消弥。当落差足够大时，就会很少人愿意做这个转换工作。而为了减少落差，一是等底层实现的发展，但这是整个it界的事情，不是mda开发者的个人问题。另外就唯有减低模型定义的高度，比如andromda，很多现成的模板都只依赖于uml静态class图，同时使用大量的tagged value，看上去和一个xml格式的自定义模型没什么区别。
所以，一来受底层实现的制约，二来omg的结构也不像个很高产的组织，mda忽然爆发，大家洗脚上田不用再coding的机会不大。但随着aop,meta-data,o/r mapping,ioc container这些底层的发展，还有微软dsl对uml的冲击，mda还是会继续慢慢发展，毕竟这是我们的梦。
当下还是挑些轻量级的代码生成方案比较实际。我挑的是xml格式的自定义模型 + jsp/freemarker模板。当然也可以像appfuse那样用xdoclet，但我觉得xdoclet的扩展性，管理性和适用范围都是最低的。也可以不用模板，用c#/java程序完全控制代码的生成，这种方式现在又多了python,ruby这些动态语言可供选择。
但我还是习惯模板多一些。比如jsp，可以用httpclient访问jsp，获得返回内容来生成文件。而xml格式的元数据， 可以通过filter放入到request或者session中。
不过，现在流行velocity和freemarker。两者之间可以用三局两胜制决出。 一，freemarker网站上有一篇文章，列出了freemarker语法上比velocity优胜的地方。 二，但现在的pm不能够这么狭隘的从纯技术角度看问题的了，velocity有着比freemarker多得多的用户群体，比如andromda, intellij idea。 三，又但是，对于这种用xml格式定义的元数据，freemarker有一个很少被提到，但无匹的优势–内置了xml dom的访问语法。比如以下的元数据： <table> <column name="id"/> <column name="name"/> </table>
freemarker可以这样列出table下所有column的name：
<#list table.* as column> ${column.@name} </#list>
对比velocity要使用jdom的api，简单了不知多少倍。就这点，让freemarker胜出，因为code generate的过程中，实在要访问太多的xml元数据。也是这点，让我在jsp和freemarker间模棱两可。本来，因为生成的是代码，不是页面，freemarker markup-language化的优势并不存在。而jsp的好处是人人都懂，而且有最好的ide，扩展性还超强，可以做任意的事情。
不过，说到底， 用什么做模板，其实不是件很重要的事情，这里只是写一下group memoring，记录低决定的过程。
