language-agnostic - 为什么我应该使用代码生成器

Question

我最近遇到了这个话题，不明白为什么需要它们。

你能解释一下为什么我应该在我的项目中使用它们以及它们如何让我的生活变得轻松吗？

例子会很棒，我可以从哪里学到更多这个话题。

Answer 1

至少您从正确的角度提出了问题=)

使用代码生成器的通常原因是生产力和一致性，因为它们假设解决一致和重复性问题的方法是向其抛出更多代码。我认为，任何时候你在考虑代码生成，看看你为什么要生成代码，看看你是否可以通过其他方式解决问题。

一个典型的例子是数据访问。您可以生成 250 个类(架构中的每个表 1 个)有效地创建表网关解决方案，或者您可以构建更像域模型的东西并使用 NHibernate/ActiveRecord/LightSpeed/[pick your orm] 来映射丰富的域模型到数据库中。

虽然手卷解决方案和 ORM 都是有效的代码生成器，但主要区别在于生成代码的时间。对于 ORM，它是在运行时发生的隐式步骤，因此本质上是单向的。手卷解决方案需要在开发过程中生成代码的明确步骤，并且生成的类可能需要在某些时候进行自定义，因此在重新生成代码时会产生问题。开发过程中必须发生的显式步骤会在开发过程中引入摩擦，并经常导致代码违反 DRY(尽管有些人认为生成的代码永远不会违反 DRY)。

吹捧代码生成的另一个原因来自 MDA/MDE 世界(模型驱动架构/工程)。我对此没有太多关注，但我没有提供一些表达不佳的论点，我只是要选择其他人-http://www.infoq.com/articles/8-reasons-why-MDE-fails .

恕我直言，代码生成是极少数问题中唯一的解决方案，每当您考虑它时，您可能应该重新审视您正在尝试解决的真正问题，看看是否有更好的解决方案。

真正提高生产力的一种代码生成类型是“微代码生成”，其中使用宏和模板允许开发人员直接在 IDE 中生成新代码，并通过占位符(例如命名空间/类名等)进行选项卡/键入.这种代码生成是 resharper 的一个特性，我每天都大量使用它。在大多数大规模代码生成失败的情况下，微生成受益的原因是生成的代码不会绑定(bind)到必须保持同步的任何其他资源，因此一旦生成代码，它就像所有其他代码一样解决方案。

@约翰
将“基本类”的创建从 IDE 转移到 xml/dsl 中经常出现在进行大爆炸式开发时——一个典型的例子是开发人员试图将数据库逆向工程为域模型。除非代码生成器写得很好，否则它只会给开发人员带来额外的负担，因为每次他们需要更新域模型时，他们要么必须进行上下文切换并更新 xml/dsl，要么必须扩展域模型然后将这些更改移植回 xml/dsl(有效地完成了两次工作)。

有一些代码生成器在这个领域工作得很好(LightSpeed 设计器是我唯一能想到的 atm 设计器)，它们充当设计表面的引擎，但通常
这些代码生成器会生成无法维护的糟糕代码(例如 winforms/webforms 设计界面、EF1 设计界面)，因此会迅速抵消从使用代码生成器获得的任何生产力优势。