Home > Development > WCF and nHibernate Can Live Together in Peace

WCF and nHibernate Can Live Together in Peace

WCF and nHibernate are two rather useful technologies for creating say SOA Entity Services[1].  WCF, particularly in .NET 4 makes it extremely easy for authoring a communications conduit whilst nHibernate unquestionably does to DB access as WCF does to communications.  Whether or not nHibernate has a place in large scale enterprise is a topic for another day.

I recently came across some peer code which cleverly defined a custom WCF service behaviour for initialising nHiberate when the service is first accessed and then for each method call.  It made good use of  the ability to utilise .NET attributes applied to the service class so developers in effect merely had to add one line of code to turn a WCF service into a DB-aware one. Quite well done I thought.

A problem occurred though when one wanted to just see if the service was published correctly by browsing to the .svc file in a web browser.  Instead of the usual WCF greeting displaying pseudo client code in a web page, an error and stack dump was displayed mentioning something about nHibernate.

Unfortunately, the mere presence of the class-level attribute meant that the nHibernate custom service behaviour was being called and I had not setup my database or some such.  Interestingly the error occurs even though we were not invoking any methods.  This meant it was technically difficult to verify the successful publication or hosting of the WCF service.  More disturbing was that it now broke all my MS Test tests for instantiating and invoking my WCF service.  Needless to say TeamCity was now displaying lots of red lights.

We discussed this and came up with an idea of moving the nhibernate service behaviour into the service configuration (in this case the web.config file) rather than hard code it explicitly with attributes or inline code.  I’m a great fan of defining behaviour by configuration irrespective of what technology the config is persisted as.  The beauty of this approach is that we can take advantage of web.config transforms for each build configuration.  Configurations for build, release, with DB and without.  Just perfect for continuous integration testing of the service itself but also deployed testing between client and service.

WCF allows you to define your own custom service behaviours and register them in the config file. This can be done manually by web.config heroes or via the magnificent WCF Service Configuration Editor.

First you need to define an Element Extension. Basically this represents the XML node in the config file. It acts as a moniker for creating an instance of your extension.  It is this moniker that the Service Config editor detects and not the behaviour extension itself.

public class NHibernateServiceBehaviourExtensionElement : BehaviorExtensionElement


protected override object CreateBehavior()


return new MyNHibernateServiceBehaviour();


public override Type BehaviorType


get { return typeof(MyNHibernateServiceBehaviour); }



Then to define the actual extension:

public class MyNHibernateServiceBehaviour : Attribute, IServiceBehavior { … }

Put both of these into ideally the same assembly.  Because of the way WCF and the Service Editor works the assembly will need to be in the same path.  This is arguably not feasible for all occasions so we elected to place them in the GAC.  Luckily nhibernate, log4net, hibernatinglamas (or was that rhinos) are all strong named.

With that done, I recommend that you use the WCF Service Config tool to do the next bit.  After all, if this part fails then it will most likely will in production.


Save that to your typical config transforms and then it keeps everyone happy, even grumpy slappers of nHibernate such as me. 😉  This approach will allow you to have full debug WCF-only configs for local testing; full debug WCF+DB testing;  CI WCF only and CI WCF+DB.  Configs for all occasions.

Happy happy joy joy!

[1] Thomas Erl, Patterns of SOA Design

Categories: Development Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: