NHibernate.Remote code preview

It gives me great pleasure to announce that NHibernate.Remote is at the stage where a community preview is possible.  It is still very raw software and not intended for any production environments, however it may give you a few ideas.

NHibernate.Remote is a WCF client for the popular ORM mapper NHibernate . For a long time when a user of NHibernate wanted to cross domain boundaries there was a lot of work involved in getting the NHibernate data over whatever means of communication was chosen.  A specific set of CRUD methods had to be set up for each persistent type, data types had to be serialized and don’t even think about using the awesome lazy loaders remotely.  Well with the advent of WCF I started thinking that there had to be a better way to exchange NHibernate data in an all .net world.  I realize what I am doing breaks all the rules of SOA but I’m only working with .net clients so I can justify it, right?  The major hurdle involved getting open generics to pass over WCF.  Anyone that has tried this out-of-the-box knows that the serializer throws a nasty error, but there is another way.  I created a generic messaging system library that would allow me to pass generic messages back and forth over WCF.  To that I added a method router that handled generic types to allow generic methods to reach their counterparts on the server.  Thus armed with a communications method that supported generics, I was able to get a lot of the ISession functionality to transmit over the wire to a remote client including LazyLoaded entities.  Not only are the lazy loaded entities transmitted, but they are also reattatched to the remote session so that their functionality is preserved.  Now then,  I have to say right here, don’t get your hopes too high because this technology is still in its infancy.  Right now saving only supports objects that have Guid’s as their primary keys, criteria queries are not working, and the testing has been very minimal.  However generic HQL queries are definitely work as well as a “Linq esq” DynamicQuery language I have been working on.

So how do you get ahold of this technology?  At this point you will have to use Subversion, as I have no intention of releasing a binary until the technology becomes more mature.  However if you are versed in subversion you can grab the source here.


I welcome any and all comments about my code and if you happen to want to help out with the project then by all means contact me.

If you want to take a look a the GenericMessaging system then you can grab the source for that here.


Keep in mind that this is preview code only and is still under heavy development. I hope to have more documentation available as the project matures in the coming months.

 Comming Soon:  A brief how-to get started

9 Responses to “NHibernate.Remote code preview”

  1. Tim Scott Says:

    Wow, this is awesome. I have written about this subject here: http://lunaverse.wordpress.com/2007/05/09/remoting-using-wcf-and-nhibernate/

    I have been sorely dismayed that lazy loading over WCF was impossible (or so I thought). When I get time, I will definitely see about applying this to the application I discuss in the article.

    Question, is this open source? Under what license?

  2. admin Says:

    Thank you for your comments. I have read your excellent article as it was one of my starting points on the road to trying get NHibernate working over WCF. Using the NetDataContract serializer is the key to getting more complex .net objects over the wire intact. However I think that I will be trying to replace/extend it soon with a custom serializer that will support reattaching lazy entities and synchronizing remote objects. Right now that heavy work is being done mostly with reflection and that carries a performance penalty especially when working with large object graphs.

    As far as the software license goes, I’m pretty new at this sort of thing. I will probably be releasing it under the LGPL license. Basically, all I ask is that if you use the code and do some enhancements that you contribute those enhancements back to the project either in a separate project or back to the main code tree so that other people can benefit.

  3. Steve Says:

    Hello – I was wondering what the status is of this project?

    I would like to use NHibernate + WCF with Silverlight

  4. Daniel Guenter Says:

    Hi Steve,
    At the present moment this is just a technology preview. Meaning that it is not suitable for production use in any way. However it is definitely improving as time goes on and I’ll be posting updates to this site.

    If you are just looking to do simple transfers of NHibernate objects over a WCF connection I suggest you check out this post. NHibernate.Remote is really attempting to be a complete data layer framework over WCF.


  5. Pete Grazaitis Says:

    I have been looking at NHibernate + WCF for Silverlight as well. I am curious how well NHibernate handles serializing some object, and when it comes back, how it handles persisting (updating vs saving). I read a couple things on “Change Tracking” in the Linq world with respect to WCF. I would think the same issue exists with NHibernate.

    Has anybod run into issues with Session management and “Change Tracking”?

  6. Daniel Guenter Says:

    Linq to sql is not very intelligent when it comes to NTier senarios. I attempted to use Linq to sql with WCF back when it first came out but with very little success. Of course there is the other issue with decorating your business models with persistence information but that is a whole other story.


    NHibernate takes a much different approach when it comes to change tracking. Rather than using a special entity it just snapshots the entity when it is pulled and when it comes time to save it compares the entity with the snapshot (At least this is what I see from looking at the source). NHibernate does provide an easy way of reattaching detached entities with the Save, SaveOrUpdate, and Update methods on a data session. I think NHibernate is workable in an NTier environment, it just takes a bit of work.

  7. Steinar Dragsnes Says:


    This is exactly what I’m looking for!

    Just one question, if I understood you correctly, then you can also send the ISession instance together with the data to the remote client. This enables lazy-loading easily since the object graph has not become detached. The downside with letting the session live for more than one single client request – server response is that the session will grow and get larger and may also become outdated and throw StaleDataExceptions. Since it is so easy to reattach entities, sending the session over to the client is not really needed anyway, or what do you think?

    There are some discussion about this subject here (http://forum.springframework.net/showthread.php?p=8004#post8004), although this is for .Net Remoting, many of the same issues apply when it comes to lazy loading.

    I’ll definitely take a close look on your solution to this WCF issue 🙂


  8. Daniel Guenter Says:

    Unfortunately it’s not as easy as serializing an ISession and sending it to the client. ISession is usually based off of the the SessionImpl class in NHibernate and while that is serializable the StatefulPersistenceContext that contains all of the entities and tracks changes will not be serialized along with it. There is also the problem that a session is usually tightly coupled with a Factory that cannot be serialized as well as a direct connection to the database. I believe the solution lies with creating a new class that uses ISession and then routing its commands through WCF. There is a lot more work to do to get a complete implementation.

    The more classic accepted approach would just be to write CRUD services in WCF and use the Save, Update and SaveOrUpdate methods on the server side to reattach the stale entites as they are transmitted from the client.

  9. Steinar Dragsnes Says:

    Yes, that is what I’m currently doing, although the service is not responsible for any creates. I also close the session on response and do not keep it alive on the server either as it minimizes the potential for stale data. A new session is created when the server gets a new request from a client and detached entities can easily be reattached to that new session. That is how I currently manage my sessions using the OSIV pattern.

    What you are doing here is very interesting. I haven’t had time to check it out yet but it is on my todo-list.


Leave a Reply