我真的很想知道您对Java和/或.NET的模型驱动软件开发的看法。
节省时间吗？它会提高质量吗？
答案 0 :(得分：8)
MDA是一个有点过载的概念。有时它意味着将UML或其他类型的图表转换为可执行代码。我现在从未见过这方面的工具。它通常会导致项目获得结果非常快，然后造成维护噩梦，因为可用的工具并不真正支持大型团队在视觉图表上工作，因为人们开始在图表中工作以及生成的代码。
我看到的东西看起来很像域驱动设计被称为MDA，如果你的意思是我全都是为了它： - ）
答案 1 :(得分：7)
我在IBM Rational Rhapsody for C ++的项目中使用MDSD。该模型非常接近UML，因此我们没有真正的域特定语言。但我仍然声称使用MDSD。根据我的经验，MDSD有很多好处：
a）使用MDSD有助于将SW架构带入复杂的层次。你总是在一个非常抽象的层面上工作，思考大局。牛仔编码软件通常缺乏良好的架构，因为开发人员陷入细节。使用MDSD，我看到了我的工作倾向，用适当大小的类，漂亮的模式或简单的代码来解决问题。
b）使用MDSD，SW的大图文档往往更好。当然，有些工具可以自动生成代码中的类图。但是这些图表由1000个类组成，您没有看到感兴趣的方面。使用MDSD，您可以专门绘制系统的一个方面，同样的图也用于生成代码的一部分。
c）建模有助于处理固有的系统复杂性。我想说，如果没有计算机辅助设计的支持，有些系统太复杂了。没有巨大的SW工具的帮助，没有人会设计CPU。使用SW帮助您编写更复杂的SW。
d）使用MDSD有助于遵守编码风格指南。获得一致的代码风格没有比让规则集生成代码更好的方法了。
MDSD当然也有一些缺点： d）如果你有一个模型，你希望每一行代码都来自该模型。并且可能难以将外部库包含到项目中。因此，要么您接受这样的事实，即您的系统基于外部组件，或者您重新发明轮子以将其纳入您的模型。
e）使用版本控制工具时，建模工具可能会遇到问题。合并源代码通常比模型图更简单。这迫使团队从复制编辑合并移动到锁定编辑合并工作流程。
答案 2 :(得分：2)
巴兹。
我相信OTOH，是在运行时进行建模。不要生成代码，而是让模型在运行时保持活动状态，让您的应用程序成为这些模型的运行时解释器。
我不知道这是否已经为Java做了。对于Smalltalk，请参阅Seaside中使用的Magritte。
答案 3 :(得分：1)
我认为这更可取。这就是我试图暗示this question关于MVC-ARS而不是MVC。 ARS（动作/表示/状态）按设计包含在模型中，可防止控制器或视图过载。
答案 4 :(得分：1)
模型驱动的软件开发不只是关于MDA，还有一系列其他方法，包括可能更受欢迎的领域特定语言方法。
当然，代码是'a'模型，但在DSL中捕获更高级别的模型是表达相同意图的更简洁方式。关键是始终从模型生成代码，而不是允许独立修改生成的代码。
有很多可用的工具，以及大量已发布的材料，包括案例研究，如果您不满意购买现成的发电机，可以告诉您如何构建自己的发电机。可以说，这比使用通用编程语言更能控制。
答案 5 :(得分：0)
这听起来确实不错，但我还没有看到它以一种实际工作方式实施。
我这样说：代码是模型。这样，您的模型和代码始终是最新的： - ）
答案 6 :(得分：0)
如上所述，我发现有两本我认为有助于理解MDA的书，这是一个广泛的主题。
由于案例研究很无聊，你不需要阅读Guttman的所有内容来获得这个想法，但是介绍很愉快。
答案 7 :(得分：-1)
MDA通常难以在服务器端层内集成业务规则，因为模型视图映射由生成的代码处理，而功能挂钩作为事件响应者提供。
我还没有看到像Forté（或者UDS，现在死了）+ Express那样强大的MDA工具。我认为具有Forté功能的MDA以及实现独立服务层（如ActiveRecord或EntityTransactionManager模式）的更好模式将成为任何平台的杀手级应用。
针对三层MDA方法的实际应用问题是，那些设置和适应特定要求非常困难。想想ABAP和SAP费率