我们是否使用代码生成工具(除了用于生成代理的工具以及从Visual Studio内置的设计器之外)？

我们会生成应用程序的哪一部分？

我们通常会自己滚动发电机吗？如果是这样，则我们要编写哪种类型的生成器(asp模板，coddom等)。如果没有，我们使用什么第三方工具？

我目前正在从事几个不同的项目，所有这些项目均使用自定义代码生成器，该代码生成器处理生成数据库结构，业务实体，DAL和BLL的所有内容。我对其他人使用这些工具的经历感到好奇。

解决方案

我们曾经使用CodeSmith来生成NHibernate hbms，我们的实体以及其他一些东西。一段时间后，我们厌倦了这种流动，因此我们放弃了它。

T4生成器是免费的，值得研究生成。

我们仍然使用Castle CodeGenerator生成MonoRail链接。

我们有一个内部构建的代码生成器，负责数据库访问。编写存储过程并获取网关类中抽象的相应方法。

我们还生成了Web服务，以便与Flash -i.e正确接口。以理智的方式处理异常。

最后，我们有一个异常生成器，消除了异常最佳实践(大量的构造函数等)的麻烦。

在以前的雇主那里，我们有一个本地开发的VB.NET应用程序，该应用程序会将XML架构定义文件(XSD)转换为静态C ++库。这使得使用C ++数据类型(bool，std :: string等)变得更加容易，并且所有有趣的XML代码都隐藏在这些生成的类中。

当我进行经典的asp工作时(大约在2001年)，我开始回滚自己的生成器(数据访问，存储过程等)。我慢慢地移到了CodeSmith，因为它更容易处理。我仍然主要只是为.NET代码生成所有数据访问层类型的东西(包括sproc)。

几年前，我从宏代码生成(即CodeSmith)跃升为微代码生成。

所不同的是，使用CodeSmith，我为我的应用程序生成了大量的代码，这些代码全部是通用的，并且一次全部生成。这对于边缘情况变得很成问题，并且在更改模板的源(即表结构)时会重新生成。我还遇到了很多情况，这些情况我没有使用过，但是都是从模板中生成的。所有这些方法都有效吗？也许吧，也许不是。进入并清理生成的代码将是一项艰巨的工作(即在同一代码库上运行了一年以上)。

相反，微代码生成使我能够在所需的正确场景中准确生成所需的类。我执行此操作的主要工具是ReSharper。我这样做的方法是在编写生产代码之前编写单元测试。在这种情况下，ReSharper使用我的单元测试作为模板来自动生成生产代码的框架。然后，只需要填补空白即可。

对于数据访问，我不再生成任何东西。我发现良好的O / R M取代了我过去在数据访问层(即NHibernate)中放置的所有内容。鉴于此，我将永远不会写或者生成另一个数据访问层(我拒绝这样做)。

另外，我得到了拥有大型单元测试套件的好处

是的，但是我们称他们为实习生。

我们刚刚在办公室开始使用Grails。以前，我们有一组内部JSF / Hibernate CRUD生成脚本。

……Grails胜了。 Grails的代码生成非常好，可以让我们在大约15分钟内启动一个CRUD应用程序，而无需实际将代码放入代码文件中！

当然，当我们要修改它时，它可以将实际的代码生成到代码文件中。在大多数情况下，对于常规CRUD，我们只需更改视图就可以摆脱困境。

• 我们使用代码生成器来处理异常
• 为CRUD操作生成DAO
• 使用JAXB生成代码
• 使用XDoclet生成EJB本地/本地接口
• 使用Velocity模板生成业务模型的文档
• 使用Apache Axis生成WSDL存​​根

我曾经使用过一种方法来生成可序列化的数据对象，这些对象可以在不同的平台(Windows，Linux，Solaris，Mac，bsd等)上进行重组。这是一个内部解决方案。

几个月前，我遇到了ActiveWriter，它为我提供了很大的帮助，我喜欢这种方法的灵活性，它生成处理数据访问问题的部分类，并且使我可以对这些类的业务部分进行编码。我感到非常满意，因为这为我节省了很多工作，更改架构，重新生成并继续进行非常不错。

我写了一个可爱的工具，使用我为之编写解析器的数据格式的专家，他们可以通过Web表单提交自己的样本，查看输出，并告诉我它是否正确。

由此，将生成一个jUnit测试。迷人的。

除了没有一个人打扰使用它，而且我没有收集任何测试用例。

我为某些任务创建了自己的工具。从长远来看，这样做很有趣，甚至可以节省时间。
对于非常乏味的任务，它甚至可以节省理智。

由于Fog Creek软件的内部语言Wasabi内置了编译时代码生成器，因此我们使用它们来自动创建映射到数据库表的实体类的内容。因此，我们无需编写具有许多不同属性和方法的类，而可以编写：

<ActiveRecord("Kiwi")> _
Class CKiwi
End Class

和CKiwi将为其在Kiwi表的基础架构中定义的每个列具有Load(ix Int32)，Commit()和字段/属性。它使我们不必拥有庞大的O / R M库，但仍然允许我们快速在产品中添加表格。

我在一个哲学阵营中，认为代码生成器是"错误的"，因为它们表明应将某些内容作为语言的一部分。

但是编写实用的代码已成为实用程序员的道德原则的重要组成部分，并且在实践中，如果默认情况下隐藏生成的代码，则代码生成效果很好。无论我们想成为多么纯洁的哲学，这种语言都不会像我们想解决的问题那样迅速发展。

我想到在Visual Studio中构建Windows窗体时生成的代码。我们可以根据需要查看生成的代码，但是最好不要这样做。但是，使用WPF迁移到声明性语言会更好，因为与命令式代码相比，以编程方式操作声明性代码更加简洁可靠。

他们应该对LINQ-To-SQL类做同样的事情。对于仅具有属性且没有自定义行为的类，它们需要一种声明性语言。使这些实体类动态化可能会更容易-当基础数据库架构更改时自动更改。

我们尝试使用CodeSmith为数据库中的所有表生成.NetTiers类，但遇到了两个问题：

• .NetTiers肿，并且生成的代码巨大。我认为代码生成工具太容易让人生厌了。
• 由于该架构正在积极地开发和修订中，因此我们也不得不重新生成很多文件，最终由于将所有文件都重新生成和替换，很难将所有内容保留在源代码控制中。我最终不确定所生成的代码是否应该完全在源代码控制中。

生成代码的最佳位置应该是在编译器或者构建阶段，而不是设计阶段。当我们在C＃中使用匿名类型或者方法时，编译器会即时进行代码生成。如果在设计阶段生成代码，则会得到大量的东西，每当基础参数发生变化时，这些东西都必须重新生成。

像这里的其他一些人一样，我们还创建了自己的代码生成器(Inon Datamanager / Viewmanager)，用于数据访问，HTML表单处理和某些业务逻辑操作。使其运行良好的关键是对其进行设计，以使我们不必触摸或者查看生成的代码。

这样，它几乎成为了语言(在我们的例子中为Java)扩展为包括域模型规范和视图模型的语言的一部分，然后我们只需用真实的Java代码填充自定义业务逻辑即可。

这为我们提供了与分析人员和业务用户进行交流的正确工具，同时仍具有Java的功能来设置基本行为的详细信息。

本着编译器精神的代码生成可能很棒。统一地以"向导"的精神生成代码已被证明是一个坏主意。

自制代码生成器非常适合从最终用户电子表格构建单元测试用例，该电子表格包含应如何工作的示例。

有关一个示例，请参见构建测试用例的工具。

并不是说我们在.net / web域中工作，而是来自各种本地设计语言的自制代码生成工具是我们开发工具链中至关重要的部分。我们有两个主要的此类工具(带有语法和解析器以及形式化定义)，还有许多次要工具，它们基于m4和perl之类的宏构建。它们最终都会生成纯C，并由本机编译。

根据我的经验，特定于领域的语言是提高程序员工作效率的关键工具之一，对于任何大型软件而言，这种努力都是如此。如果我们要构建具有许多重复出现的模式的编译器，模拟器或者其他非常复杂的软件，而这些重复模式根本不支持基本语言(通常表示可移植的C，有时甚至是C ++)，那么代码生成工具就是理想之选。我将领域特定的语言视为一般化的下一步：首先将通用计算分解为函数(或者具有历史意义的子例程)，然后将通用函数分解为模板或者泛型(如果可用)，然后分解更加通用，并将代码重复成成熟的自定义语言。

这一切都是为了减少我们实际编写的代码量，并从编程过程中删除任何形式的繁琐重复和非增值代码。一旦模式重复出现，请应用特定领域的语言！

我们使用LLBLGen来生成我们的数据访问层。我们将生成器指向我们正在使用的数据库，选择要使用的表，然后生成所需的类。这一切都非常快速和容易。

如果我们对LLBLGEN非常感兴趣，那么我们可能还会评价亚音速。甚至甚至可以了解Rob Conery对于亚音速和t4之间的任何重叠或者相互作用要说些什么。

我编写并使用了基于Xslt的代码生成工具。 http://perfectstorm.codeplex.com/

这使用单个根xml模型来生成dal，proc，表。