I have been working on code generation lately and have finally made a breakthough that will make life easier for most projects. I have been following the techniques found in Kathleen Dollard’s (KD) “Code Generation in .NET” book.
The intent of the book was to demonstrate code generation techniques with a sample generator.  A lot of people have gone with her generator as if it were a product.  This misses the point – the generator is easy to write it is the base classes, templates and techniques that are important.  The book was about the process not the product!

I have gone for an even more bare-bones generator than KD.

My transformation process goes:

model.codegen  + template – XSLT ->  batch file

batch file runs a series of:

model.codegen + transform + parameters -> generated code/scripts &c

The big thing is that all generation comes from one document via xslt.

So far I am generating:

• Table creation scripts
• Data access layer
• Stored Procedures
• Model to dal mapping code

I am planning on generating:

• Model
• View
• Controller
• View to Model Mapping code

The beauty of this is it all uses XSLT and requires only one custom exe. I have also found that performing the transform as a single match makes it easier to read the transform.  That is don’t call other templates – all in one complex document.

The real trick is to develop an “application minature”.
This is a small application that has one or two screens that demonstrate each of the classes that will be used in the finished application.  This is handcrafted.  This is used to create and fix the templates and the metadata document.
you may need to adjust it to match the slightly weaker coding standards that must be applied to XSLT.

You create this small application that provides just enough functionality to provide the principles involved.  This may only have a handful of model classes.  New techniques can be experimented with easily and if they generate well they can be rolled out the full application.  This has the benefit of making the entire application to be consistent.  There will be none of we experemented with that but were stuck with it.  The best idea is to have no exceptions – everything is one of the standard options. Of course you can add handcrafted code – but this must be for the truely exceptional cases.

The big stumbling block is the application framework (that is how to solve the problem). If you have an application then you should be able to extract a framework from the best parts.  If not look for a framework that solves your problems or build or buy one.  You must understand the template, the generation process and your framework.  If something does not fit then change it.  This allows new ideas to be put into production rapidly.

These techniques work very well when combined with a very pure MVC or MVP framework.  If you avoid explicit duplication in your code this will make your life very easy.

This is a book about code generation.

From the two chapters that are publically available it seems that he knows what he is talking about.

My current take on codegen is to simply use xslt.

I have an extended xslt utility that I use.

The syntax is:

xslt source transform target [name value]*

This allows one root document to be used to create a batch file that generates the used code from the one core document.

It has a few other tricks (handling or header comments and logging changes), but that is about it.
It does include some string  manipulation extensions.