代码生成器与代码重构

Question

您对CRUD程序的喜好程度如何？代码生成，框架驱动或手动编写？

Answer 1

我对代码生成器的经验是，它们是一个良好的开端，但在更改已经解决之后，我通常希望手动重写模块。当然，这可能成为一个维护问题。但它真的变成了“一条绳子有多长”的问题。 您正在处理哪些生成器，框架和资源？其中一些是处理恐怖，其他人可以正常工作。

Answer 2

我喜欢使用自定义模板的代码生成器，原因如下：    减少编码工作量    易于进行全球变化    在模板中嵌入架构可确保开发人员合规性    编码错误的可能性更小。    一致的功能    少测试。

事实上，使用代码生成器，我可以在更新架构时，在几分钟内从60多个表中修改数据库创建或重新创建存储过程，实体类和DAL。通过使用自定义模板，我确保所有图层都符合我的命名规则，并确保正确的错误处理和防止双重插入。

非常适合固定价格合约。如果是每小时，那么你可能想要手工完成： - ）

Answer 3

如果您使用.Net使用Linq，那么它很容易维护。 LinqToSql使您可以轻松更新数据模型，而无需更改代码。

Answer 4

我喜欢框架驱动和手动编写的混合体。我已经对NHibernate和LinqtoSql做了一些工作，有时他们为我生成的查询需要一些帮助。

Answer 5

这实际上取决于您的应用程序的大小。手工制作的数据访问层对于非常小的应用程序最有意义，因为您拥有最终控制权，但对于任何中型到大型应用程序，我都会推荐代码生成器。我有过各种APEX SQL（不太好），LINQ和Subsonic（非常好）的经验。我即将评估Telerik ORM，但我想这也会很好。

Answer 6

在我看来，代码生成器是设计糟糕的标志，并且违反了DRY。好的框架会让你维护更少的代码。使用框架，您最终还是扩展和重构代码而不是代码模板。

Answer 7

框架是选择之一，如果我需要使用代码生成器，我喜欢将生成代码的快速Perl脚本放在一起，这样我就可以准确理解生成的内容和原因。

Answer 8

如果您将用户视为数据输入员，以便为您维护数据库表，则它们非常有用。它们有助于最大限度地缩短满足最低要求所需的编程时间。

如果你希望你的工作质量能够反映出比这更好的东西，那么对他们来说最好的是，如果你不太确定如何自己做简单的一致UI屏幕，他们可能会给你一个快速启动。 / p>

就我个人而言，我发现根据实际用例将它们重构为有用且有吸引力的东西需要比从头开始做更长的时间。他们是Dilbert尖尖的老板会喜欢的那种技巧。

Answer 9

我发现CRUD逻辑的优秀框架比代码生成器更好。当一组复杂的表生成一个非常慢的查询以产生结果时，我遇到了这种情况。