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.

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)

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.?

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.

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.

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.

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.