This morning, Scott Hanselman presented his rather interesting talk on Code Generation (ARC305). I have mixed feelings on the subject -- I love the idea of generating chunks of code but I usually loathe the quality of the code. On top of that, often generated code can't be modified or built upon easily. For instance, I love the fact that you can generate typed DataSets using the xsd.exe utility, but the code it produces is really bad and you can't add stuff to it, such as raising an event when a certain property changes -- which is what I like to do. Anyway, back to Scott's presentation.
The basic idea of straight code generation is to build a specification, or call it a domain model if you will, for instance in XML files. You then have these XML files parsed, maybe along with some code templates (think CodeSmith or RapTier again), producing source code or compiled output (as in the case of xsd.exe). The key to making it successful is to shape it to fit your development processes and the domain you're working in. Obviously, if you're building small smartphone apps your code-generation procedure and the output is going to differ from your missile guidance system project. So you can make the input format (the XML schema for the domain models) as simple or as complex as needed, and provide very complex and flexible or very simple input templates.
Of course, you don't have to limit yourself to generating source code. You can generate documentation and unit tests as well, possibly even Word documents (using WordML) or, why not, Excel sheets with statistics?
Personally, I like to work with automated build systems that generate compiled Help files too, by tweaking Visual Studio.NET's project files before compilation (so that XML generation is turned on) and running NDoc on those XML files after compilation. In addition to code-generating tools such as CodeSmith, I also like to use ReSharper's template functions to automatically generate properties that raise xxChanging and xxChanged events, check for null input and the like. That's code generation too, but not the command-line variety that Scott was talking about. Digressing again...
Scott raised an interesting point when he talked about using WSDL as your specification language. Yes, WSDL was originally created for specifying the public APIs of web services -- it stands for Web Service Description Language, after all -- but that doesn't have to keep you back. Why not just use WSDL's syntax to specify entity classes, data access operations etc.? All you have to do is leave out the binding part and the Web Service discovery part of the WSDL, or replace it with something more meaningful to your code generator.
What's also nice about Visual Studio 2005 and .NET 2.0 is the partial classes feature, which fixes, in a sense, the “I can't edit this generated code” problem. To put in code that can't be generated off your model, you can tweak your code generator to output partial classes and then add code in other files that together make up the final class.
Later this week there's a session planned on NHibernate, the .NET version of Java's Hibernate which claims to be able to generate entity classes and business classes off databases and custom models. A couple of Java guys I'm working with use Hibernate and they're experiencing real pains with it. It'll be interesting to see how far NHibernate goes, and if it really is the holy grail that can generate half of any client/server app's code... Stay tuned, more to come on that subject!