我真的很想听听我们对Java和/或者.NET的模型驱动的软件开发的看法。

节省时间吗？它会提高质量吗？

解决方案

回答

听起来确实不错，但是我还没有看到以实际可行的方式实现它。

我这样认为：代码就是模型。这样，模型和代码将始终保持最新：-)

回答

MDA有点超载。有时，这意味着将UML或者其他类型的图转换为可执行代码。我从未见过使用当今可用的工具可以很好地解决这个问题。这通常会导致项目真正迅速地获得结果，然后造成维护噩梦，因为可用的工具并不能真正支持大型团队在可视化图表上的工作，并且人们开始在图表和生成的代码中工作。

我已经看到了一些看起来很像域驱动设计的东西，称为MDA，如果我们是说我全力以赴的话:-)

回答

由于模型视图映射由生成的代码处理，并且功能挂钩作为事件响应程序提供，因此MDA通常很难在服务器端层内部集成业务规则。

我仍然没有看到像Fort(或者UDS，现在已经死了)+ Express一样强大的MDA工具。我认为具有Fort功能的MDA和更好的模式来实现独立的服务层(如ActiveRecord或者EntityTransactionManager模式)对于任何平台而言都是杀手级应用。

针对三层MDA方法的实际应用存在的问题是，要设置这些MDA方法和使其适应特定要求非常困难。只需考虑ABAP和SAP汇率

回答

我认为这是可取的。这就是我要暗示的关于MVC-ARS而不是MVC的问题。 ARS(动作/表示/状态)通过设计包含在模型中，可防止控制器或者视图过载。

回答

仅仅投入两本书，我发现如上所述对理解MDA很有用，这是一个广泛的主题。

• MDA提炼-模型驱动架构的原理。 (梅勒)
• 真实的MDA：使用模型驱动的体系结构解决业务问题(Guttman)

案例研究变得无聊时，我们无需阅读所有Guttman即可理解，但是介绍很容易阅读。

回答

嗡嗡声。

我所相信的OTOH是在运行时进行建模。无需生成代码，而是让模型在运行时保持活动状态，并使应用程序成为这些模型的运行时解释器。

我不知道这是否已经为Java完成。对于Smalltalk，请参阅在海边使用的Magritte。

回答

模型驱动的软件开发不仅与MDA有关，还有其他一些方法，包括可能更流行的领域特定语言方法。

当然，代码是" a"模型，但是在DSL中捕获更高级别的模型是表达相同意图的一种更为简洁的方法。关键是始终从模型生成代码，而不是允许独立修改生成的代码。

如果我们不愿意购买现成的发电机，则有很多可用的工具以及大量的案例研究案例，可以告诉我们如何构建自己的发电机。可以说，这比使用通用编程语言给我们更多的控制权。

回答

我在带有IBM Rational Rhapsody for C ++的项目中使用MDSD。该模型非常接近UML，因此我们实际上没有特定于域的语言。但是我仍然声称会使用MDSD。根据我的经验，MDSD有很多好处：

a)使用MDSD有助于将SW体系结构提升到复杂的水平。我们总是在非常抽象的层次上思考大局。牛仔编码软件通常缺乏良好的体系结构，因为开发人员会陷入细节中。使用MDSD，我发现我的工作趋向于用足够大小的类，漂亮的模式或者只是更好的代码来解决问题。

b)使用MDSD可以更好地记录SW的大图文档。当然，有些工具可以根据代码自动生成类图。但是这些图包含1000个类，我们看不到感兴趣的方面。使用MDSD，我们可以专门绘制系统的一个方面，并且使用完全相同的图来生成代码的一部分。

c)建模有助于解决固有的系统复杂性。我要说的是，有些系统过于复杂而无法在没有计算机辅助设计支持的情况下进行构建。没有庞大的软件工具的帮助，没有人会设计CPU。使用SW可以编写甚至更复杂的SW。

d)使用MDSD有助于遵守编码风格准则。获得一致的代码样式没有比让代码由规则集生成更好的方法了。

MDSD当然也有一些缺点：
d)如果我们有一个模型，则希望每一行代码都来自该模型。而且可能很难将外部库包含到项目中。因此，或者我们忍受这样一个事实，即系统基于外部组件，或者重新发明轮子以将其纳入模型。

e)建模工具可能会遇到使用版本控制工具的问题。源代码通常比模型图更易于合并。这迫使团队从复制-编辑-合并转移到锁定-编辑-合并工作流程。