The ORM Foundation

I created the simplist of all possible ORM models, Person smokes, and generated the C# code for the model.

This produced 1650 lines of code, which contained one lonely comment on line 1647. On the plus side the code compiled.

In order to begin to understand the code I generated unit tests using the VS2005 unit testing feature. This produced 173 unit tests.  

This seems like an awful lot code and a huge surface area for such a small model.

I'd like to understand more about the architecture and design. Could someone reply with an overview?

Also any tips on getting the code to run would be appreciated. ;-)

jMM

The first 1200 lines or so are essentially static. They provide support classes that are used by any and all class models that we generate. We currently generate these support classes for each model, which will actually cause naming conflicts if you have more than one generated class model in the project. We are exploring a couple of approaches for improving this process.
The generated code consists of two parts: the public interface, and an implementation of that interface. The public interface consists of an abstract classe for each of the primary entities from the model, as well as a "context" interface. The context interface serves as a sort of "controller," providing factory methods for creating instances of each of the abstract classe, and keeping track of these instances.
The implementation currently generated consists of a single context class (that implements the context interface). This class also contains private, nested concrete implementations of each of the abstract entity classes.
To use the code, you should be able to just create an instance of the context class and then go from there. For example, if your model is named "MyModel", the process would be something like:

MyModelContext context = new MyModelContext();
context.CreatePerson(/* appropriate parameters here */);
etc.

Hi,
  Interesting.  I wonder how much is due to the fact that you are crossing from one paradigm to another.  With a persective and goal of lining up with the Relation Model, ORM is structure oriented.  C# is a programming language - process.  A RDBMS uses process to establish and manage structure, using the process of programming to do that. One of the great effciencies of Relational Databases is that they deal with enitire sets of data, unlike the way programmers are accustomed to looping through, one item at a time.  Small wonder programmers like cursors in RDBMS - it's in thier comfort zone.  As Kevin pointed out, there's a lot of overhead to bridge the gap between the two methodologies.  BRN..  

I had a similar experience to John.
Six facts with three objects generates two simple tables but 4400+ lines of very hard to follow C#.

What I expected to see were a few class structures that relate to the tables.

If one unary fact creates 1600 lines of C# 
and six binary facts create 4400 lines of C#

It looks as though one binary fact generates about 600 lines of C#
Thus, by inference, 100 facts are going to generate around 60,000 lines of C#.

Something seems to be not quite right with this.
What is the explanation?
What is NORMA doing to generate such a lot of code?
Is it ignoring the .NET framework or what?

Ken

The reason for the large files in the current state of the code generation is that it isn't just creating code fragments for the user to fill in later. It is generating a full implementation of the object model with constraint enforcement etc.. Currently several data access layer implementations are being developed. All of which will delegate the majority of the constraint enforcement to the database. The only code that the user should have to deal with is the public abstract classes and the context interface.