Coding, is? Fun!

Thursday, July 19, 2007

Framework Development - Code generation

Persistence frameworks, for rapid development, usually ride on generated code. I have worked with different tools, custom, commercial, that let you point at a database table, or an XML file and generate classes. They also generate stored procedures for CRUD operations.
We faced several decisions regarding such code generators - should we use Codesmith, or build our own? Should we integrate with Visual Studio? How do we make sure the spewed code is not modified, but is extended correctly? Do we use the table as the master schema or spew XML and then generate code from XML?

Integrate with Visual Studio
I think to have a code generator plug-in is very convenient and increases productivity remarkably. But it is also troublesome to install and to supply configuration. Plus it is overkill upfront. We will use an independent generator for now and then develop (or buy) a plug in separately later.

How to extend spewed code
I have seen code generators that use a XML, XSLT model to generate code; or use templated code (as Codesmith does); or just write out lines of code from a generator. In general, you spew code from a database table schema. Then you go ahead and write some business logic in the spewed class. But the spewed class may need to be respewed for additional modifications.
To manage this, some tools detect that the spewed class has changed and show a manual merging tool.
Ideally the class file should not be modified at all - but that is almost impossible to enforce. I have seen some good innovative solutions using partial classes (in .NET 2.0). You split the same class into a spewed, unchangeable class file and a changeable class file. You can add business logic to the changeable class file.
You can manage the same using a spewed, unchageable base class and a changeable sub class.
Visual Studio, of course, spews code all the time - when designing WinForms screens. In MFC using Visual C++, they would just request you not to change some lines.
I think actively trying to prevent developers from changing the spewed code is kind of overkill (atleast in internal applications). I think you can use a convention of storing spewed classes in a separate folder and then hoping that nobody changes them. On the other extreme, we can avoid spewing code at all; generate and compile the code dynamically during the build process using a custom build action. That makes sure nobody can modify these classes. (XML Serialization does something similar).
For now, I am tending towards a loose approach - we spew the code and hope everybody changes the subclasses (which are also spewed along with the base classes). If necessary we will tighten up later (by taking the person who changes the spewed code outside and shooting him).


XML is king?
One of the ideas is that we spew XML (with column names, datatypes) from the table schema and use that as the basis for generating code. This has its advantages - you can add some custom properties in the XML and regenerate code. What if you wanted a property to be readonly? You can add that as a custom attribute to the XML.
The core issue is that a table schema does not contain ALL the information that you can play around with in a C# class. As we saw, marking a property as readonly is an example. So, philosphically I like the XML file idea. But it is not practical to maintain a separate spewed XML file AND a spewed class file.
The problem is that people can mess up the XML and cause the table schema and XML to grow apart.

So, for now, no XML. We will be generating code from a generator; storing in separate folders; and then subclassing from these classes, if we want to extend them.

Labels: , ,

2 Comments:

  • "We will be generating code from a generator"

    Is the generator created by us with the CodeSmith model?

    Also, if the generated code is not going to be compiled assembly, and users might need to have a look at it, then we might need to provide facility to spew code in VB.Net also (these are longterm thoughts?).

    And about Log4net usage and its complexity (is it complex to use?), we might provide a wrapper to that thirdparty tool and simplify the logging feature...if possible, we might add this in the starter kit automatically so that programmers should just do some configuration if at all needed and just call a simple method to log wherever they need in the program. (do we have any plan like that to have a vstemplate for creating web projects?)

    By Blogger Venkat, at 10:21 PM  

  • Codesmith - probably. But that makes it difficult to make this open source (because Codesmith is not open source). We need to think about that.
    For now, VB.NET is out of question. Long term, sure.

    Log4net is not complex to use. I have used it with such a wrapper that you suggest. The point is do we really need another third party tool for that purpose.I lean towards reducing such dependence.

    There is no plan as yet for a starter kit or a VS template. Those will be addons. If at all we do some suhc thing, it will be using the Software Factory model, that Microsoft uses. That will be useful to learn.

    Probably one of us should spend some time on looking into the software factories and packaging.

    By Blogger Ramiah Ariya, at 10:58 PM  

Post a Comment

<< Home