你使用代码生成工具吗？

Do you use code-generation tools (aside from those used to generate proxies and from designers built-in to visual studio)?

您是否使用代码生成工具(除了用于生成代理的工具和内置于visual studio的设计器)?

What part(s) of your application do you generate?

您生成的应用程序的哪些部分?

Do you typically roll your own generator? If so, what type of generator do you write (asp templates, coddom etc.). If not, what 3rd party tools do you use?

你经常推自己的发电机吗?如果是这样,你会写什么类型的生成器(asp模板,代码等)。如果没有,你使用什么第三方工具?

I am currently working on a few different projects wich all use a custom code-generator that handles everything from generating the database structure, business entities, DAL, and BLL. I am curious about other peoples experiences are with these kinds of tools.

我目前正在开发一些不同的项目,它们都使用自定义代码生成器来处理从生成数据库结构,业务实体,DAL和BLL的所有内容。我很好奇其他人的经验是用这些工具。

21 个解决方案

#1

I'm in the philosophical camp that considers code generators to be "wrong", because they indicate something that should be made part of the language.

我在哲学阵营中认为代码生成器是“错误的”,因为它们表明应该成为语言的一部分。

But it's been a big part of the Pragmatic Programmer's ethic to write code that writes code, and in practice code generation works well if the generated code is hidden by default. No matter how philosophically pure you want to be, the language will never evolve as fast as the problems you want to solve.

但是编写编写代码的代码是实用程序员的道德规范的重要组成部分,并且在实践中,如果生成的代码默认隐藏,代码生成也很有效。无论你想要多么纯粹的哲学,语言永远不会像你想要解决的问题一样快速地发展。

The code that gets generated when you build a Windows Form in Visual Studio comes to mind. You can look at the generated code if you want, but it's a better idea not to. Moving to a declarative language with WPF was superior, however, because it's cleaner and more reliable to manipulate declarative code programmatically than imperative code.

我想到了在Visual Studio中构建Windows窗体时生成的代码。如果需要,您可以查看生成的代码,但最好不要这样做。然而,转向使用WPF的声明性语言是优越的,因为以编程方式操作声明性代码比命令式代码更清晰,更可靠。

They should have done the same thing with LINQ-To-SQL classes. They need a declarative language for classes that just have properties and no custom behavior. It probably would make it easier to make those entity classes dynamic--changing automatically when the underlying database schema changes.

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

We tried using CodeSmith to generate .NetTiers classes for all the tables in our database, but ran into two issues:

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

.NetTiers was bloated, and the code generated was enormous. I think code generation tools make it too easy to creature feep.

.NetTiers很臃肿,生成的代码非常庞大。我认为代码生成工具太容易让人产生麻烦。
Because the schema was being actively developed and revised, we had to regenerate a lot, too, and that ended up making it very difficult to keep everything in source control because all the files were being regenerated and replaced. I ended up being unsure if the generated code ought to be in source control at all.

由于模式正在积极开发和修改,我们也不得不重新生成,并且最终使得很难将所有内容保存在源代码控制中,因为所有文件都在重新生成和替换。我最终不确定生成的代码是否应该在源代码控制中。

The best place for code generation should be in the compiler or the build phase, not the design phase. When you use an anonymous type or method in C#, the compiler is doing code generation on the fly. If you generate code during the design phase, you get a chunk of stuff that must be regenerated every time the underlying parameters change.

代码生成的最佳位置应该是编译器或构建阶段,而不是设计阶段。在C#中使用匿名类型或方法时,编译器会动态执行代码生成。如果您在设计阶段生成代码,那么每次基础参数发生变化时,您都会获得一大块必须重新生成的东西。

#2

Yes, but we refer to them as interns.

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

#3

Not that we are working in the .net/web domain, but home-made code generations tools from various home-designed languages are a crucial part of our development tool chain. We have two major such tools (with grammars and parsers and formal definitions), and a host of minor one built on macros like m4 and perl. They all generate plain C in the end, which is natively compiled.

并不是说我们在.net / web域工作,而是来自各种家庭设计语言的自制代码生成工具是我们开发工具链的重要组成部分。我们有两个主要的工具(带有语法和解析器以及正式定义),以及一些基于m4和perl等宏构建的小工具。它们最终都生成了纯C,这是本机编译的。

Domain-specific languages are one of the key tools for programmer productivity for any large-scale software endeavor in my experience. If you are building things like compilers, simulators, or other very complicated software with many recurring patterns that have no support at all in the basic languages (which typically means portable C and sometimes C++), code generating tools is the way to go. I view domain-specific languages as the next step in generalization: first you break out common computations into functions (or subroutines to be historical), then you break out common functions into templates or generics if such a facility is available, and then you break out even more commonality and repeating code into a full-blown custom language.

在我的经验中,领域特定语言是程序员生产力的关键工具之一,适用于任何大型软件。如果您正在构建诸如编译器,模拟器或其他非常复杂的软件,其中包含许多在基本语言中完全不支持的重复模式(通常意味着可移植的C,有时候是C ++),那么代码生成工具就是最佳选择。我将领域特定语言视为概括的下一步:首先将常见计算分解为函数(或子程序为历史),然后将常用函数分解为模板或泛型(如果有这样的工具可用),然后中断更加通用,并将代码重复为完整的自定义语言。

It is all about reducing the volume of code you actually write, and removing any form of tedious repetition and non-value-added code from the programming process. As soon as patterns repeat, apply a domain-specific language!

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

#4

I started rolling my own generators (data access, sprocs, etc) back when I was doing classic asp work (circa 2001). I slowly moved to CodeSmith, since it was much easier to deal with. I was still primarily just generating all the Data Access layer type stuff (including sprocs) for my .NET code.

当我做经典的asp工作(大约2001年)时,我开始回滚我自己的生成器(数据访问,sprocs等)。我慢慢转向CodeSmith,因为它更容易处理。我仍然主要为我的.NET代码生成所有数据访问层类型的东西(包括sprocs)。

A couple years ago, I made the jump from Macro Code Generation (i.e. CodeSmith) to Micro Code Generation.

几年前,我从宏代码生成(即CodeSmith)跳到微代码生成。

The difference is that with CodeSmith I was generating huge swaths of code for my app, all generic, and all at once. This became problematic for edge cases and regenerating when changing the source for the template (i.e. table structure). I also ran into cases where there was a high inventory of carrying code that I wasn't using, but was generated from my template. Did all those methods work? Maybe, maybe not. Going in and cleaning up the generated code would have been a huge amount of work (i.e. after more than a year on the same codebase).

不同之处在于,使用CodeSmith,我为我的应用程序生成了大量代码,所有代码都是通用的。这对边缘情况和在更改模板的源(即表结构)时重新生成成为问题。我还遇到了一些案例,其中存在很多我没有使用的携带代码,但是是从我的模板生成的。所有这些方法都有用吗?也许,也许不是。进入并清理生成的代码将是一项巨大的工作(即在相同的代码库上超过一年)。

Micro Code Generation, in contrast, allows me to generate exactly the classes I need, in exactly the right scenario I want. The primary tool I use to do this is ReSharper. The way I do this is by writing my unit tests before writing my production code. In that scenario, ReSharper uses my Unit Test as a template to auto-generate the skeleton for the production code. Then it's just a matter of filling in the blanks.

相比之下,微代码生成允许我在我想要的正确场景中生成我需要的类。我用来做这件事的主要工具是ReSharper。我这样做的方法是在编写生产代码之前编写单元测试。在这种情况下,ReSharper使用我的单元测试作为模板来自动生成生产代码的骨架。然后,这只是填补空白的问题。

For Data Access, I'm no longer generating anything. I've found that a good O/R M replaces everything I used to put in my data access layer (i.e. NHibernate). Given that, I will never write or generate another data access layer in my life (I refuse to).

对于数据访问,我不再生成任何东西。我发现一个好的O / R M取代了我以前放入数据访问层的所有内容(即NHibernate)。鉴于此,我将永远不会在我的生活中编写或生成另一个数据访问层(我拒绝)。

Plus, I get the benefits of having a large unit test suite, among other things

另外,除了其他方面,我还可以获得大型单元测试套件的好处

#5

Since Fog Creek Software's in-house language, Wasabi, has compile-time code generators built in, we use them to automatically create the meat of our entity classes that map to database tables. So instead of writing a class with a dozen different properties and methods, we can just write:

由于Fog Creek Software的内部语言Wasabi内置了编译时代码生成器,我们使用它们来自动创建映射到数据库表的实体类的内容。因此,我们可以写下:而不是用十几种不同的属性和方法编写类。

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

and CKiwi will have Load(ix As Int32), Commit(), and fields/properties for every column defined in its underlying schema for the Kiwi table. It keeps us from having to have huge O/R M libraries, but still allows us to quickly add a table to our products.

和CKiwi将为其Kiwi表的基础模式中定义的每个列具有Load(ix As Int32),Commit()和fields / properties。它使我们不必拥有庞大的O / R M库,但仍允许我们快速向我们的产品添加表格。

#6

Code generation in the spirit of compilers can be great. Code generation in the spirit of "wizards" has uniformly turned out to be a bad idea.

编译器精神的代码生成可能很棒。以“巫师”为精神的代码生成统一证明是一个坏主意。

#7

We used to use CodeSmith to generate our NHibernate hbms, our entities, and a few other things. After a while we got sick of this flow so we ditched it.

我们曾经使用CodeSmith生成我们的NHibernate hbms,我们的实体和其他一些东西。过了一会儿,我们厌倦了这种流动,所以我们放弃了。

The T4 generator is free and worth looking into for generation.

T4发电机是免费的,值得研究一代。

We still use the Castle CodeGenerator for MonoRail link generation.

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

#8

We use Code generators for Exceptions

我们使用代码生成器进行异常

Generating DAO for CRUD operations

为CRUD操作生成DAO

use JAXB to genereate code

使用JAXB生成代码

Use XDoclet to genereate EJB local/home interfaces

使用XDoclet生成EJB本地/ home接口

Use Velocity templates to generate documentation for business models

使用Velocity模板生成业务模型的文档

Use Apache Axis to generate WSDL stubs

使用Apache Axis生成WSDL存根

#9

I met ActiveWriter a couple of months ago and it helped me very much, what I like is the flexibility of this approach, it generates partial classes that handle the data access issues and it lets me code the business part of the classes. I feel very satisfied cause saves me a lot of work, it´s pretty nice to change the schema, re-generate and go on.

几个月前我遇到过ActiveWriter,它对我非常有帮助,我喜欢的是这种方法的灵活性,它生成了处理数据访问问题的部分类,它让我可以编写类的业务部分。我感到非常满意,因为我节省了很多工作,改变架构,重新生成并继续下去非常好。

#10

I create my own tools for some tasks. Its fun to do and even saves time in the long run. For very dull tasks, it even saves your sanity.

我为某些任务创建了自己的工具。它很有趣,甚至可以节省时间。对于非常沉闷的任务,它甚至可以节省你的理智。

#11

Home-brewed code generators work great for building unittest cases from end-user spreadsheets that contain examples of how it should work.

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

See Tooling to Build Test Cases for one example.

有关示例,请参阅工具来构建测试用例。

#12

We use LLBLGen to produce our data access layer. You point the generator at the database your using, select which tables you want to use and it churns out the classes needed. It is all very quick and easy.

我们使用LLBLGen来生成我们的数据访问层。您将生成器指向您正在使用的数据库,选择要使用的表,并生成所需的类。这一切都非常快捷方便。

#13

We have an in-house built code generator that takes care of database access. One writes stored procedures and gets corresponding methods abstracted in a gateway class.

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

We also generate web services in order to properly interface with Flash -- i.e. handling exception in a sane manner.

我们还生成Web服务以便与Flash正确连接 - 即以理智的方式处理异常。

Finally we have an exception generator that takes away the drudgery of exception best practices (tons of constructors, etc...)

最后,我们有一个异常生成器,可以消除异常最佳实践(大量构造函数等等)的苦差事。

#14

At a previous employer, we had a home-grown VB.NET application that would turn an XML Schema Definition file (XSD) into a static C++ library. This made it much easier to work with C++ data types (bool, std::string, etc.), and all of the interesting XML code was hidden inside of these generated classes.

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

#15

We just started using Grails here in the office. Previously, we had a set of in-house JSF/Hibernate CRUD generation scripts.

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

... Grails wins. The code generation from Grails is very nice and can get you a CRUD app going in about 15 minutes, without actually putting the code in the code files!

...... Grails赢了。 Grails的代码生成非常好,可以在大约15分钟内为您提供CRUD应用程序,而无需将代码放入代码文件中!

Of course, it CAN generate the actual code into the code files, when you want to modify it. Most of the time, for regular CRUD, you can get away with just changing the views.

当然,当你想要修改它时,它可以在代码文件中生成实际代码。大多数情况下,对于常规CRUD,您只需更改视图即可逃脱。

#16

I've used one to generate serializable data objects which could be reformed across different platforms (windows, linux, solaris, mac, bsd, etc). It was an in-house solution.

我用过一个生成可序列化的数据对象,可以在不同的平台(windows,linux,solaris,mac,bsd等)上进行改造。这是一个内部解决方案。

#17

I wrote a lovely tool in which the experts in the data format I'd written a parser for, could submit their own samples through a web form, look at the output, and tell me whether it was correct.

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

From that, a jUnit test would be generated. Lovely.

由此,将生成jUnit测试。可爱。

Except that not a single person bothered to use it, and I gathered no test cases whatseover.

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

#18

Like some others here, we have also created our own code generator (Inon Datamanager/Viewmanager) for data access, HTML form handling and certain business logic operations. A key to having this work well is to design it so you never have to touch or look at the generated code.

与此处的其他人一样,我们还创建了自己的代码生成器(Inon Datamanager / Viewmanager),用于数据访问,HTML表单处理和某些业务逻辑操作。让这项工作做得好的一个关键是设计它,这样你就不必触摸或查看生成的代码。

In this way, it almost does become part of the language - the language (Java in our case) is extended to include a domain model specification and a viewmodel, and then you just fill in custom business logic with real Java code.

通过这种方式,它几乎成为了语言的一部分 - 语言(在我们的例子中是Java)被扩展为包括域模型规范和视图模型,然后您只需用真正的Java代码填充自定义业务逻辑。

This gives us the right tools to communicate with analysts and business users, while still having the power of Java to set up the details of underlying behaviour.

这为我们提供了与分析师和业务用户进行通信的正确工具,同时仍然具有Java的强大功能来设置基础行为的详细信息。

#19

If interested in LLBLGEN, which is excellent, you might also evaluate subsonic. Maybe even see what Rob Conery has to say about any overlap or interaction between subsonic and t4.

如果对LLBLGEN很感兴趣,那么你也可以评估亚音速。甚至可以看看Rob Conery对亚音速和t4之间的任何重叠或相互作用有什么看法。

#20

I wrote and use an Xslt based code generation tool. http://perfectstorm.codeplex.com/

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

This uses a single root xml model to generate dal, procs, tables.

这使用单个根xml模型来生成dal,procs,tables。

#21

I have created a custom code generation framework that generates proxy classes for web services in several languages such as Java Script, Action Script, Java, C# and Objective C, I use no templates or tools just plain C# code that generates code with some helper classes, Code generation can really save a lot of time, but I think the generated code should be as simple as possible and should not be overused.

我创建了一个自定义代码生成框架,它以多种语言生成Web服务的代理类,例如Java Script,Action Script,Java,C#和Objective C,我没有使用模板或工具,只使用普通的C#代码生成带有一些帮助类的代码代码生成确实可以节省大量时间,但我认为生成的代码应尽可能简单,不应过度使用。

#1