Revolutionary (versus Evolutionary) Code Generation

It's just about time to throw out all my code and rewrite it in {x}. Again.

Many of the changes to the .net framework in the last few years have allowed me to get away with just refactoring some of my code, or perhaps discarding the ugliest portions of it. Over time it seems to reduce down, like a knob of butter simmering on a hot plate.

But with the syntax changes in 3.0, it seems that almost everything I've written can be rearranged into a simpler style. And the biggest effects will be felt in the data access code: this means my use of code generation is set to change drastically.

First up -- a short run down of my general approach in regards to code generation.

The Evolutionary Approach

1. Write good code, manually.

Even if you'll eventually 'generate' the code, you want to first be an expert at writing it manually.

This is the wax-on, wax-off part of the game.

2. Move logic away from the user interface, into 'business' classes.

User interface and 'business logic' will each go through big changes -- indpendently of each other. Separating the two is such common advice that it's often treated gospel to many. Either way, it's usually worth it.

3. Refactor code into small reusable portions where possible.

You want to avoid repetition. So where the same code is repeated in slightly different ways, you extract this into a small helper class, or a utility function.

The code is now smaller, and neater -- but it's not gone altogether.

4. Convert what's left into templates

Take the remaining code, look at what overall patterns exist and convert the code into templates (CodeSmith for me, kiddo!) to accomodate accordingly.

A fair rule of thumb is that you should have carefully written it by hand three times before extracting it into a template.

Now, when the code generator does its work, the generated code will be the best possible code.

In theory.

So if things are going well...

The goal is to have:

1. no repetition in manual code.
2. no need to customize generated code.
3. no logic in forms/code behinds.
4. 'business logic' in 'business classes'
5. Generated code where necessary. Less is more.

And this is evolutionary because?

Over time, as the framework improves... the libraries and templates evolve, just a little bit.

For example, when nullable types were introduced, it became easier to talk to the database (where fields are natually 'nullable').

Hence, the templates were improved in places, and the helper functions were reduced or improved in places.

Generics were a big change. Writing 'type-safe' collections went from being 'code-intensive' to trivial, e.g.(List<Person>). This made the 'list template' simpler, but didn't get rid of it altogether.

The introduction of partial classes meant that rather than customizing a generated class through inheritance, it could be done by adding a partial class. This was neat -- but hardly reduced the code that was generated.

I mentioned a revolution...

Now, I'll probably move to using Linq to SQL -- and a lot of the fundamental code generation will now be handled by the Linq To Sql generator. This is a revolutionary moment: and revolutions are not without their bloodshed.

I'm expecting trouble. I'm expecting confusion. I'm expecting mistakes.

Linq to SQL will be generating code using the goodness of Linq. Great, wonderful, shiny. But. Unlike my own CodeSmith templates, it'll be generating the sort of code that I don't yet have the experience to write manually. That's a worrying shift.

And what of the generated code it replaces? Will it replace everything that my current DAL's do? And where it falls short, can I customise the generator? Or do I need to generate extensions through a separate tool?

How good is the Linq to SQL ORM designer? I've seen already that I can't right click on a table and 'refresh'. This was a glaring oversight that annoyed me in the first five minutes... What else is in store? Is this thing ready to be part of the core process in big 'line of business' apps?

Actually... shiny new tools to play with... I guess the answer is... Bring It On!

(am i the only one who accidentally types 'ling' when i mean 'linq'? (no))

Also -- by the way, since no one I've spoken to seemed to realise this: you can get Linq to work on .net 2.0 sp1 machine, if you include the right dll's with your project.

My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.