Enhancement: Separate NHibernate config code from model code

Hi,

related to this post,

http://www.mindscapehq.com/forums/thread/328252

I have an idea for an enhancement:

Problem: if you do a manual configuration of the session factory, which is good practice if you deploy your app and add a little configuration tool with your setup, the manual configuration code is overwritten each time you update your model with the designer.

This behavior took me some hours today because suddenly my application stopped working after I edited the model in the designer. And the last place I was looking for was the automatically created class by the designer ;-)

I talk about this section which is used with your app.config normally:

public static Configuration CreateConfiguration()
    {
      var configuration = new Configuration();
      configuration.Configure();
      ApplyConfiguration(configuration);
      return configuration;
    }

Manual code here is overwritten by the Designer.

Solution: Put this code into a separate class which will be created only once, when you start to design your model. This code normally never changes again if you use app.config, if you use your own configuration technique it will never be changed again by the designer. If you update your model you can check if this class exists and don't recreate it in this case.

Regards, Kay

The CreateConfiguration() method just returns a Configuration object, not a session factory. You can perform manual configuration on the returned Configuration object before you create your session factory.

However, if there is something you need to do that has to happen before we return the Configuration object, you don't need to call our CreateConfiguration method at all. You can just copy our code into a class of your own, modify it as required, and call your version instead of ours. Really all CreateConfiguration is doing is remembering to call our generated ApplyConfiguration() method for you, and that's a public method so you can easily call it from your own code.

We would be interested in knowing what sort of additional code you want to run though -- if the pattern you're using would be useful to other NHibernate devs then it would be great to encapsulate it or provide a hook to make it easy for them to plumb in!