nHibernate mapping files no more

During an evenings coding, I ran into a typical problem with an nhibernate mapping file, (it was a spelling mistake) I had one of those moments when you go onto google to see if any one has come up with something smart to tackle this. I design from the the domain model  first so i was not looking for a code generator that you point at a database and way it goes. I was looking for a OO approach to this that removed xml from the mix.

It was a successful google search, I came across Fluent-NHibernate.

This sample code snippet was enough to stop my search and get me excited.

public CustomerMap : ClassMap<Customer>
  public CustomerMap()
    Id(x => x.ID);
    Map(x => x.Name);
    Map(x => x.Credit);
    HasMany<Product>(x => x.Products)
    Component<Address>(x => x.Address, m =>
        m.Map(x => x.AddressLine1);
        m.Map(x => x.AddressLine2);
        m.Map(x => x.CityName);
        m.Map(x => x.CountryName);

What appeals to me about this code above:

  • The fluent interface and the use of lambda’s makes it very readable.
  • As its a class, I can group all my map objects into a single assembly. Then let the concerning layer in my application reference it, keeping my domain model persistent ignorant. (Before I came across “Fluent nHibernate” I was going to resort to using attributes)
  • Thinking ahead, when/if I refactor my entities, resharper will also make changes to map objects.
  • I am a TDD/BDD practitioner, Its an object, i want to put my mapping logic under test.
  • Lastly, no need for xml mapping files any more.

So I read some more, downloaded the code and had a play.

You can get an idea of how this works in about 5 minutes by running the quick start. The instructions and general documentation on this site is a little light on the ground and not much more info on the web at the moment to give more depth on the usage of this API.  The quick start uses a Cat object as the entity to persist.  I don’t really come across to many cats, dogs or other animals in programming so I wanted to used a real life example to get a better feel for it. At the moment to get assemblies, you need to checkout the code from the svn truck and compile the code yourself.

Running the Quick start

To aid the quick start instructions

  1. Create a new folder on PC and checkout the code from the SVN trunk “http://code.google.com/p/fluent-nhibernate/source/checkout&#8221;.
  2. From your working folder. Open up the quickStart solution and build it.
  3. As the context is ORM you need a database to push and pull data from. I had an instance of sql express to hand, so I created a blank database called “test”.
  4. Back to Visual studio, in the “FluentNNibernate.QuickStart” project, change the connection string in the app.config to point to your database.
  5. The quick start does not have an UI to use, but its behavior is expressed in the integration tests. Open up “QuickStartTester.cs”, find the “Export_Schema” method (which is decorated with the Explicit nunit attribute) and run the test (I used Test driven .net to run the test). This will create a new table in your database.
  6. Now run the “Can_Persist_Cat” test method. This tests creates an instance of Cat, populates it and saves, it. Lastly the test, pulls the data from the database by the id and compares the ids.

This is a very simple test but enough to wet my appetite. I have a working example using more business like entities on this post here Implementing Fluent-nHibernate.


Overview of the ModelView – ViewModel (MVVM) pattern and data-binding

In my own learning of WPF or any technology that I learn, I use the same approach and design principles that I would for a technology I know inside out. I have used winforms for years and I would be modest to say I know how to design a winform application the right way. It would be the approach I would use if I was developing an application in java swing. I would at the forefront of my design use the “model view controller” (MVC) pattern. The MVC pattern has been around since I was born and has been discussed and debated to death over the years. MVC aside I would use a number of other design patterns that fit the  bill for concern situations. For example: I would use command objects to do certain actions which could be wired up to menu items and/or buttons.

Model View Controller

The MVC pattern is a compound pattern, meaning that MVC is made up of other design patterns used together. MVC is made up of the “Mediator” and the “Observer” patterns (I and not going to discuss the details of these patterns as I want to keep to the subject matter, for more information on this patterns I recommend the Gang of Four web site and I might put a post together in the future).

Although MVC is a well established pattern, I have read other blogs and stuff in forums and the opinion of what MVC is, is very mixed. MVC in the .NET world seems to have become more wide spread over recent years which is good but MVC is not just about “Separation of Concerns” which some people I have worked along side believe. I can not remember where I got this from but the rules I follow are:

  • Model = what it is.
  • View = what it looks like.
  • Controller = what it does.

MVC is a pattern and as such is a guideline and the implementations of the pattern vary. Variations of MVC exist like “Model-View-Presenter” (MVP) and “ModelView-ViewModel” (MVVM). In a very brief explanation:

MVC – The view sits at the top of the architecture, the controller sits below the view. The model sits below the controller. So the view knows about the controller, the controller knows the model. The view is notified when the model changes.

MVP – The controller is replaced with a presenter. The presenter sits at the same level as the view. The presenter listens to the events of both the view and the model and mediates the interactions between both the view and model.

MVVM – The controller is replaced with a view model. the view model sits below the UI layer. The view model exposes the data and command objects that the view needs. You could think of this as a container object that view goes to to get its data and actions from. The view model pulls its data from the model(s) below.

I read a blog by Josh Smith on “the code project” once where he talked about MVC and WPF and he stated “lower the flamethrower”. I echo his comments.

If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. … Some of the purists out there will inevitably have qualms with what I refer to as “MVC”. Feel free to leave a flaming comment on the message board at the bottom of this Web page. I will gladly entertain different perspectives on what MVC means, but keep in mind that I do not care.


The word Data-binding used to bring back bad memories of using data-binding in older technologies. In Winforms .net 2.0, it was not perfect, it was ok for simple things like binding data grids and text boxes and drop down boxes but using a date time picker was painful. The .net framework contains a number of interfaces and classes (“system.componentmodel”) that allowed you to implement better data-binding support in your own objects.  Using a custom implementation of the observer pattern with a hybrid of the data-binding interfaces was more desirable in winforms. (the memories, the pain).

But in WPF, no need to be down about data-binding, because it is excellent. Though it has a learning curve.

Data-binding is in its own right an implementation of MVC. the view are the controls that are shown in UI. the model is the object you are binding to and the controller is the data-binding component. I think its important to think about data-binding in this way.

Why is MVVM different

I believe that MVVM pattern was developed by some Microsoft developers a few years ago when developing Expression Blend. The main difference with MVVM to MVC is that the ViewModel is built to serve the view and provide the view with the data and commands it needs. The viewModel is not a general object that could serve different views but is bespoke for each view. For the TDD’ers out there its easy to define the behaviour of a viewmodel and test using a test first approach. The ViewModel is a model for the view. And the real power comes in when you bind your ViewModel to your view in WPF.

The key thing to remember is that you have one and only one ViewModel per view. The view model communicates with the model (business logic, services whatever below it). The view does not need to know about any else in your architecture. Another major plus point is that you do not any code behind your view and the data-binding deals with the communication to the view model and what ever the view model exposes.

Thats it for a quick overview. I have a draft post that i am working on that will put this into concrete code.