代码生成器与代码重构
我的代码生成器的经验是，他们是一个好开始，但在更改结束后，我通常要手动重写模块。当然，这可能会成为维护问题。但它真的变成了“多少绳子”问题。 哪个您正在处理的生成器，框架和资源？其中有些是可怕的处理，其他的工作是正确的。
如果您使用.Net使用Linq，那么它很容易维护。 LinqToSql可以轻松更新数据模型，而无需更改代码。
我喜欢框架驱动和手动编写的混合。我用NHibernate和LinqtoSql做了一点，有时他们为我生成的查询需要一点帮助。
这真的取决于您的应用程序的大小。手工制作的数据访问层对于非常小的应用程序来说是最有意义的，因为您拥有最终控制权，但对于任何大中型应用程序，我都会推荐一个代码生成器。我有APEX SQL（不是很好），LINQ和亚音速（都很好）的各种经验。我即将评估一个Telerik ORM，但我想这也会很好。
在我看来，代码生成器是坏设计的标志，违反了DRY。作为一个好的框架，你会保持更少的代码。使用框架，您最终还会扩展并重构代码，而不是代码模板。
我喜欢代码生成与以下原因自定义模板： 减少编码工作 易使全球变化 模板嵌入架构，可确保开发人员遵从。 编码错误的机会较少。 一致的功能 需要测试。
事实上，使用代码生成器时，我能够在架构更新后的几分钟内，使用60多个表修改数据库来创建或重新创建存储过程，实体类和DAL。通过使用自定义模板，我确保了所有层都符合我的命名规则，并确保正确的错误处理和防止双重插入。
适用于固定价格合同。如果是小时，那么你可能需要手工完成:-)
如果我需要使用代码生成器，我喜欢将一个快速的Perl脚本放在一起生成代码，所以我理解，框架是选择之一究竟是什么产生和为什么。
如果您将用户视为数据输入员以维护您的数据库表，那么它们非常有用。它们有助于最小化满足最低要求所需的编程时间。
如果您希望您的作品的质量能够反映出比这更好的东西，那么可以为他们说的最好的方法是，如果您不太确定如何自己制作简单的一致UI屏幕，它们可能会给您带来快速启动。
就我个人而言，我发现基于实际用例将它们重构为有用和有吸引力的东西比从头开始需要更长的时间。他们是迪尔伯特尖尖的老板会喜欢的那种技巧。
我发现一个比代码生成器更好的CRUD逻辑框架。当一组复杂的表生成了非常缓慢的查询以产生结果时，我遇到了这种情况。