Scalable Codegen Process : Application Minature

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.

Another book on codegen

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.

Composite UI Application Block

The Composite UI Application Block (CAB) is touted as a MVC framework for large scale applications.

I have had a look at the design and it seems to be rather lacking from a MVC or a MVP perspective.

I am not saying that it does not solve certain problems.  It does provide inversion of control details.  It does allow a number of forms to be wired together in a losely coupled manner.

The documented definitions of MVC are rather woolly.

The Model component has been ignored.  The model component of the CAB is any data container.
The Controller base class does not seem to be a controller in any sense.

There does not seem to be any provided support for validation.

If this is what people think MVC is it is no wonder there are no decent in-depth articles moving models or interacting controllers.

Article on MVC

This is a great article on MVC.

It covers MVC and a lot of related patterns.

It is very hard to find articles that go beyond the basics.
For example what is the best practice to allow multiple controllers to interact?
How do you decouple the database from the model?

Is it possible to reuse a controller between a windows form and a web site for a non-trivial application?

Composite Model

Over the last year and a half I have been working on a Composite Model Framework.

This uses:

  • Smart Types” for model attributes (A smart type is a primitive type that knows that it has been set and changed),
  • Explicit attached “business rule objects”
  • Rules can navigate the model using xslt

Use of the composite pattern for the model makes for a very robust model component (rules can survive the addition of nodes above them in the tree).  This is very easy to self check, maps directly to requirements, has a single obvious implementation point for almost any functionality to be added.

One of the key points is that the model is responsible for holding data, validating data and performing other buisiness functions.  The model is not responsible for data persistance.

The components of the system are:

Model (M)
View (V)
Controller (C)
Data Access Layer (D)

Typically the controllers constructor has a signature of C(M,V,D).
This allows us to keep the Model independent of the database and the View.

Most business rules belong in the model – the exceptions being referential integrity and uniqueness constraints that have to be on the database.

Literate User Interface

I have been writing a user guide for the data entry section of a website.
I had copied some of the links from the site into the document.

One of the users mentioned that is the userguide available on the website?
That got me thinking – why not embed the user interface for infrequently used code into the user manual?
The users will not fail to find the documentation and it will encourage the developer to keep the documentation upto date.