Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,549

filter by tags archive

A short note about NHibernate and Silverlight

time to read 1 min | 134 words

I got a few questions about NHibernate and Silverlight. That is actually a very easy thing to answer.

Don’t even try. They don’t get along. In fact, they aren’t even going to get along.

Silverlight doesn’t have System.Data.IDbConnection, and you can safely assume that that it somewhat important to NHibernate.

So, running NHibernate inside a Silverlight application, presumably in order to access a local database is out. But I don’t think that this is what most people actually had in mind when they ask about NHibernate and Silverlight. They want to know about NHibernate on the server and Silverlight on the client.

And that is easy enough to answer as well, it is going to work just like any client / server system. All the same rules apply.


Andrés G. Aragoneses

But Silverlight 3.0 introduces desktop applications. Do you know if System.Data.IDbConnection is available in SL3.0?

Chris Brandsma

Maybe you should direct people to NHibernate and WCF instead -- since that is how the communication is supposed to happen between Silverlight and a web server.

How about NHibernate for .Net CF instead. :)

Mike Brown

Brad Abrams has a post on using RIA services against a non-EF/L2s backend...presumably, one would be able to create the same kind of interaction with NH as well.


I suspect people asking about NHibernate and Silverlight are really meaning 'how to use NHibernate with Silverlight in a disconnected manner'

I have setup some examples of using NHibernate with Silverlight and RIA.NET. I use DTO's to the client with Automapper to map them back and forth.

I think the questions are more about 'let' say I use my NHibernate POCO objects, what is the best way in that setup to 'reattach' them to a ISession in terms of updating, optimistic concurrency concerns, etc... (Not that I use that method, but I certainly have considered it for smaller applications)

Niclas Pehrsson

I heard about a cool solution to access a local database with silverlight, and it was to install a service on the client's computer and connect to it with http://localhost:xxx/someservice/

But when you need to do this its time to question if silverlight is the right method to use. :)

Ayende Rahien


RIA works with NHibernate, but that isn't quite what I meant in the post.

Silverlight is a client side tech, RIA, at least the part that matters, works on the server.

Ayende Rahien


That is a different question all together :-)

I think you know my answer, UpdateCustomer vs. ChangeCustomerAddress

Ayende Rahien


That is... not quite what I have in mind when I think about silverlight apps.

Mike Brown

I know what you meant...but RIA would be a possible bridge between the two since it autogenerates the client side bindings.

Mark Monster

I think the requirement of a local database can be filled by using something like Local IsolatedStorage.

This might be a good solution, I never tried it though.


Huseyin Tufekcilerli

Ayende (and all the crew around here),

What do you think about NHibernate on the client side of a desktop application like a Windows Forms/WPF application directly accessing the database via NHibernate? I always try to avoid this and try to use an application server between my clients and the DB. Clients talk to server and server talks to DB (using NH of course). This way I can assess the necessary security rights in my app server. The other way around, should the clients have the credentials to the DB server and should I make security assignments to my DB tables, views, etc.?

Niclas Pehrsson

Not me either, just an wild tip when talking about client databases.

Ayende Rahien


I'll have a separate about that.

Demis Bellot

Yeah I don't like the idea of having your client application talking to a database directly either. Apart from the scalability/resource issues of each client maintaining a persistant db connection (as was done in the old days) you will also have connectivity issues when you try to view it outside your corporate firewall, it is kind of like having internal links like file://fileserver.domain.com/partypics.jpg which will only work on the Intranet.


Talking to the database directly from Silverlight client reminds of me of client side VBScript connecting to the database and creating AJAX-like functionality in HTML in the mid-late 90s.

It would certainly be a bad practice. You have to deal with a lot of connections, as noted by Demis, as well as store the connection string on a client.

Mike Griffin

Our Architecture does run under Silverlight, and requires only a single 50k assembly. Our full DynamicQuery's work as well, and our smart proxies maintain row state, it's great for writing Silverlight applications, in fact, you cannot even tell the difference from our smart proxies to our full server side classes, they are the same.



The code to make it all happen is rediculously easy ...

Ayende Rahien


Aren't you running into the Fallacies of Distributed Computing in this way?

Every time that I saw a component that pretended that the network wasn't there, it ended in tears.

Mike Griffin

Actually, no, it works great. If you look at that blog post above there are links to few other blog posts on how we do it. Basically, in your Silverlight project when you add a reference to your WCF service you can tell it to not generate proxies and instead use your own proxies. So, we can go from our lightweight proxies to our full server objects (and back again) through normal DataContract serialization. Honestly, you cannot tell the difference between the two when programming. This is exactly how it is supposed to be done, that is, DataContract is meant to serialize in and out of different classes, the the KnownTypes attribute. Look at our sample code on that post. Our save method in WCF is one line, it commits the data and returns the very same collection with autoincrement keys populated, records deleted, whatever. We've had customers working like this in WCF for quite some time, now we've made our DynamicQuery API work under Silverlight as it doesn't reference anything from System.Data or any ADO.NET code.

If you take a moment to really look at that code there is no easier way to work with Silverlight that with EntitySpaces. You lose no functionality in the ES API when running under Silverlight, You can bind your collection to a grid in Silverlight and merely send the collection back to the Server and call Collection.Save() on it. The collection knows which rows are dirty, which columns are modified, which rows are deleted, added and so on. And you can make use our full DynamicQuery API from under Silverlight and send the query to the server and get your data back just like in normal EntitySpaces programming. Our customers working with our Alpha absolutely love it. We are looking at an early September GA release. We've always had great proxy support but really put alot into them on this release specifically for Silverlight.

Peter Morris

Personally I think it is a good thing.

The lack of such functionality forces people to treat the client app as ONLY a client app, and not some massively fat client that can do anything and exposes a direct connection to the database.


I'm totally agree with Mike Griffin.

But I think such API as Dynamic Query should be open and be able to adopt to different ORMs.

ADO.NET Data Services target that problem, but it leaves much to be desired.

May be It is possible to create such API by creating some light version of IQToolkit which is not related to database classes.


You say "it is going to work just like any client / server system". This is only true, if you are using normal web services and with a few ugly tricks (big hacks) of creating a VS project that shares entities.

But is not true when using RIA services, since there are problems with many to one associations mapping. See http://silverlight.net/forums/t/109667.aspx
It seems as that NHibernate developers simply have to abandon the best thing that happened to .NET and that is Silverlight, since I dont think this will be resolved due to "nobody cares". This is really funny.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 3 days from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats