我支持MDA

既然选择了MDA ,就拿MDA去做个系统，
实践一下，然后再来谈谈体会。
其他有什么好多扯的。

其实大家只要进一步的去思索现象背后的原理，世界就可以清晰起来。图形为什么比较直观呢？首先就是图形都是比较概括的，非细节的。或者你的图形即使很细节化，但是人们观察图形也总是很概括很不细节化。
而UML就如同他的名字一样是一种建模语言，任何一种背离建模的尝试，都是和uml语言的根本基础相违背的。当然MDA很多的思想还是很好的，不过把MDA的应用范围广泛到整个的软件领域就十分的不合适了。在一个行业的某种应用中使用MDA我想确实可以使效率提高，但是MDA还要和可定制框架以及内嵌脚本竞争。

我的感觉是选择越来越多，反而更坚定了我们走自己的路的决心。与其眼睛只盯着外面，放弃了自己的尝试，不如去多实践，多思考如何在现有架构下解决好遇到的复杂问题。Rod Johnson 认为一个框架的发展应该是由遇到的问题所驱动的（一个反例就是 Entity Bean 这种靠规范委员会专家拍脑袋出来的结果），我非常赞同这个观点。如果现有的架构能够解决好遇到的大部分问题，就没有必要明天就换成一种时髦的新框架。MDA、SOA 也许都非常好，但是我们暂时还用不上，等到将来确实发现了非常适用的领域再用也不迟。

对于大部分还没有形成自己的开发平台的软件公司，我觉得 Spring 是一个很好的选择，在这个基础上可以发展出来其它的部分。比如持久层可以使用 Hibernate，Web 层可以使用 Webwork2 等等。对于已经有了自己的开发平台，并且经过磨合已经达到了比较理想的开发效率的公司，那就一直用下去好了。

对于 MDA，我一直不说什么，因为确实与我目前的工作有很大的距离。但是我有信心一旦决定去研究 MDA 会比某些人研究的深，因为我是带着问题去研究的。而我现在看到某些对 MDA 的介绍感觉都比较虚（与我们真正的编程实践经验差距比较大，我怀疑写这些文章的人是否做过大量的开发）。以前我的同事 ly 对我说如果你看到一本讲 OOAD 的书里面举的例子是 ATM 取款机，那么你就可以把这本书直接扔掉了。

实际上我知道有人已经在研究基于具体的行业的MDA，这个方向我支持。当然难度很大，不过前景也很大。而还有一个优势在于实际上MDA的底层是可以使用XSL或者其他方式转换为脚本或者XML配置文件的，而对于行业流程的规范化也是我们国家所提倡的。因此结合具体的小范围的应用，面向具体的行业项目的MDA探索是一个合适的方向。而那些希望通过MDA而生产一个CASE的想法，我看还就是一个CASE。

曾经有段时间，MDA的概念被炒作得非常厉害。后来发现MDA并没有想象得那么好

楼主说的不是MDA吧，你说的无非是使用UML进行建模，同时产生代码框架，进行快速开发，这些不过是一些开发工具的功能，比如Together、Rose等（个人认为在开发时能有用的也只是类图而已，其它的UML图只是沟通讨论时用的，最好不要有产生代码之类的念头），这些工具可以在一定范围内解决UML与代码的同步，也就是设计文档和代码同步、和反向工程的问题，和MDA不是一个范畴内的事情，有特定领域的业务框架才有谈MDA的基础。

支持建模和UML，支持类图和代码的同步，支持代码和UML图的同步。不过对MDA，没有看到什么实例的情况下，实在不敢支持。

软件开发中永远需要两种制品：
1。抽象的描述
2。具体的实现
如果MDA包含所有的实现细节，那他就不能作为抽象的描述，想一次搞定，没门！

我不认为 MDA 会达到预定的鼓吹的目标。 但也不赞成你的反对逻辑。
抽象和具体向来都是相对的。 相对于汇编， C 语言是抽象的。 相对于C , C++  是抽象的。 都一次搞定了。 :-)

宣传MDA的人总是喜欢拿 汇编语言和高级语言来说事.
但我觉得,这个类比基本不适用.
高级语言比汇编语言效率的提高在于,
高级语言更加面向问题,而不是机器.
而MDA对于高级语言来说,在面向问题方面并不会有什么大的提高.

我指的抽象是指让"人"认识系统的那些制品，
实现指让"系统"足以运行的那些制品。
从"人"到"系统"虽然存在对应关系，也能实现一些转化，
1.但如果是一次搞定的单一制品，你顾及了"系统"这一方面，"人"看这些就会不舒服。

2.你顾及了"人"这一方面，"系统"就会缺少运行的细节。

3.如果你把"人"和"系统"两边都考虑到了，那和做两次有什么区别？