Ayende @ Rahien

It's a girl

A short note about NHibernate and Silverlight

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.

Comments

Andrés G. Aragoneses
07/27/2009 10:17 PM by
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
07/27/2009 11:28 PM by
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
07/28/2009 12:12 AM by
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.

Steve
07/28/2009 12:48 AM by
Steve

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
07/28/2009 12:49 AM by
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
07/28/2009 01:16 AM by
Ayende Rahien

Mike,

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
07/28/2009 01:17 AM by
Ayende Rahien

Steve,

That is a different question all together :-)

I think you know my answer, UpdateCustomer vs. ChangeCustomerAddress

Ayende Rahien
07/28/2009 01:18 AM by
Ayende Rahien

Niclas,

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

Mike Brown
07/28/2009 01:29 AM by
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
07/28/2009 06:29 AM by
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.

http://silverdb.codeplex.com/

Huseyin Tufekcilerli
07/28/2009 06:44 AM by
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
07/28/2009 07:26 AM by
Niclas Pehrsson

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

Ayende Rahien
07/28/2009 09:08 AM by
Ayende Rahien

Huseyin,

I'll have a separate about that.

Demis Bellot
07/28/2009 10:11 AM by
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.

Dmitry
07/28/2009 02:11 PM by
Dmitry

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
07/28/2009 04:58 PM by
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.

See

www.entityspaces.net/.../...light+Demo+Online.aspx

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

Ayende Rahien
07/28/2009 10:12 PM by
Ayende Rahien

Mike,

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
07/28/2009 11:48 PM by
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
07/29/2009 08:25 AM by
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.

Alexey
07/30/2009 04:14 AM by
Alexey

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.

Sebastijan
08/11/2009 09:44 AM by
Sebastijan

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.

Comments have been closed on this topic.