Let’s approach a simple data domain problem that everyone can relate to.  I’m not going to do the e-commerce or blog demos.  This time, we’ll do something slightly different, we’re going to build a simple Product Evaluation website.

To facilitate a fair set of tests and the ability to swap these models (NHibernate, Entity Framework, and CQRS/ES) in and out, this common model will be injected through a Repository interface definition and the Unity IoC (Inversion of Control) container. For those not in the know, IoC allows objects to be built up from components defined in a configuration file somewhere else in the application.

The entities and data access for our application seem fairly simple:  Products and Evaluations.  We shall define these objects initially as interfaces, so that we can use the same Asp.Net MVC front-end project to access our domain.  This is the “O” in our ORM, our object model looks something like this:

One note: the generic IRepository is defined so that later we can add other repositories and be guaranteed that they all implement the same Get, Save, and Delete method signatures.

The approach is typical of an n-tier application with simple CRUD (Create-Read-Update-Delete) actions available in the repository for the database object being sought.  Pay close attention to that: database object.  Later in this series, this model WILL change, and the effects are profound.  I’ll stop there, I don’t want to foreshadow too much.

At this point, using the class designer and adding some comments to our 4 objects, we haven’t written any REAL lines of code, just definitions at this point.  In future posts, I’ll include NDepend metrics for comparisons and reference GitHub source / tag definitions.

My next post will go through the construction of the “R” of our ORM model – the relational database.  After that we’ll do some simple NHibernate mapping.