我能看到的MDA

很喜欢优秀的技术框架，于是想到了能否提供一个技术框架之上的业务框架呢？业务框架少不了一个相对领域内稳定的model。

受ddd的蛊惑开始很在意model，于是很顺利的看到了model-driven architecture，开始很振奋，感觉希望就在眼前。唯一遗憾的是大部分带impl部分都说尚未完成，当然实践指南就更谈不上了。不过也有一些实现的工具：

androMDA，从uml导出的xmi开始，借助xdoclet和模板生成代码。可是这算什么？一个单向的代码生成而已，唯一做的好像就是把xmi解析了一下，没有psm,没有灵活的转换规则，无法双向同步。omg描绘的好处没实现几个，坏处倒是一大堆（主要是弄复杂了）。一个半成品。

emf，借助eclipse平台的优势，实现了一个mof的子集ecore，提供uml,xml和代码之间的三向转换。挺酷的，听起来。生成的实现代码也挺灵活，只是原来的object不叫object了，叫eobject,类似还有elist,eclass，反正都是变了种的。导出的model还能做成plugin供后人瞻仰，eclipse就是酷。（研究不深，反正我没有看到太明确的出路）

这过程中翻过software factory，知道vs2005更加革命，废了uml，创了dsl,并且给出了一个过程的具体实现，还没有看到这个正式版不好评论，据说不叫mda，不过提法不一样而已，都是鼓吹一个更高层次的抽象，下一代的语言类似。都是一个调调。

好了，业务框架还是要踏踏实实的来做，怎么办呢？老老实实写一些代码，然后写一些方便配置的xdoclet扩展，顶多顶多写两个eclipse的代码向导或配置插件什么的，了事吧。一阵折腾下来，我倒是学会了给别人演示andromda和emf的“强大”功效，反正自己是不想碰了。

领域范畴的东西很难一两下子就稳定下来的，所以这些所谓的工具基本上都只能充当一个辅助角色，最终完整地实现还是要靠代码的积累。对于程序员而言，这些都只是花把式，如果要真正为开发者着想，还是想想如何提高代码的熵值重要。

不懂，目标应该是降低阿

如果代码里面需要在两处显式说明一件事情，而实际上可以通过自有的关联暗示，那么两种情况下，谁的单位熵值将会比较高？

我完全不懂 MDA，也同样完全不懂 ddd，所以只能发表一些完全外行的评论。好在我经常发表外行的评论，这里的网友对于我已经有了一些容忍度，几乎不再向我扔西红柿了。

可以去看看以前 Martin Fowler 对于 MDA 的评价。以前这里的 ozzzzzz 和 potian 两位对于 MDA 也不是非常看好。听了他们两位的评论，我的心也冷了。买的两本 MDA 的书放在书架上已经大半年，从来没有翻过。当然 MDA 也许就是将来软件开发的方向，但是正如我所说的，过早地为将来投入和过晚地投入一样都是代价高昂的。MDA 是不是现在已经成熟到了我们必须去“拥抱”的地步呢？我并不这样认为。在我看来 MDA 现在还很不成熟（最重要的标志就是是否已经有成熟的开源产品出现），让我现在就去为这样一个大厂搞出来的“大词”来买单，那是在侮辱我的智商。

根据我的从业经验，作为一个技术人员，对待这么多纷繁复杂的技术，最重要的是区别开其究竟是学术性的，还是已经真正到达了实用的阶段。对于已经到达了实用阶段，并且可以大幅提高开发效率的技术，一定要高度关注和投入很多精力去研究。因为这些技术才是真正帮助我们更好地完成工作的，我们所急需的技术。

我来举个例子，我的一位朋友认为 JDO 比 Hibernate 先进，更有前途。他的看法也许是正确的。但是问题是 Hibernate 是成熟的、开源的、可以免费获取，而 JDO 成熟的、开源的、可以免费获取的方案却几乎不存在。JDO 抽象了 OR-Mapping 的 API（越是抽象的东西就越复杂），使得可以持久化对象到关系数据库、基于对象数据库、对象数据库甚至于平面文件中。但是我只需要简单地持久化对象到关系数据库中，HSQLDB 对于我就是一个非常理想的选择。Hibernate 这种怎样方便怎样来的做事风格和我的做事风格非常接近，而 JDO 相对来说似乎学术性太浓了一些。所以从促进我的工作的角度来说，Hibernate 已经可以满足我的一切需求，Hibernate 是最好的，我只能选择 Hibernate，不可能选择 JDO。是否符合规范并不是我优先考虑的问题。那么多的 JSR，你研究的过来吗？如果我是你的老板，我不会为你做研究的过程奖赏你一分钱，我只会为你最终得到的结果而奖赏你。还是多考虑考虑如何改进手头的工作吧。

还是不懂，自关联信息也是信息阿，从信息的角度看，熵值似乎是没有变化。
刚才google了一把，没有找到程序设计与代码熵值之间关系的讨论，俺不是科班出身，可否给点链接，我自己去学学。

也不一定永远用程序员的角度看问题，偶尔在行业角度看看也不错。
前一段时间和公司的一个同事研究MDA，俺当时的认识就是局限在代码生成器上，现在看了一些书，说说认识：MDA的特点就是把一些东西规范下来，然后才有所谓代码生成的工作，由于标准化，所以可以正向和反向工作，同时制定了严格的语义规范，区别了PIM和PSM，分清了四个语义层次，让软件开发有可能成为真正的自动化工作。
俺也对MDA近景不看好，一是因为它有成为“银弹”的潜力，想把问题一次全解决，而根据经验，这种一揽子的尝试不容易成功；另外，MDA真正的价值也就是屏蔽了开发中的技术平台上的困难，但是问题还是问题，系统的复杂性一点也没减少，我最头疼的不是技术问题，而是业务上的分析和复杂性，所以对MDA不是很看重。
当然，从远景来看，至少MDA有希望减少我们这个行业中的蓝领，这也是一个好处。

那只是你的幻想，全部都去搞 MDA 了，你仍然是蓝领。而且老板从来不会象你这样想的。

软件开发在目前很大程度上还是一个创造的过程，只要这件事情不解决，MDA只会在另一个角度把同样的复杂性以不同的方式再次表述一遍

是的，这个才是问题的关键所在，也是以前 potian 所说过的问题。他说他怎么也不认为那种最终非常复杂的图形会比经过良好重构的 Java 代码更加直观、更容易理解、维护起来更方便（差不多是这个意思了）。模型是什么？模型就是简化。如果最终的模型和实际的应用一样复杂了，那就失去了模型的本来的意义。按照我的偏见，MDA 很大程度上是一群建模狂热者为了提升自己的地位而搞出来的东西（天哪，为什么没有人重视我！）。有了一把锤子，看到什么都是钉子。到处乱砸。