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

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. :)

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)

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. :)

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

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/

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

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

To see a sample of RIA Services working with nHibernate see my latest blog post: www.chrisvandesteeg.nl/.../aspnet-mvc-dynamicda...

http://www.hessiancsharp.org/ can help.

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.

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

i have never tried it but it should be possible to use CSLA.NET for silverlight with nhibernate

http://www.lhotka.net/cslalight/Default.aspx

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.

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.

So there's an alternative for those who don't want to the client-server separation route, but not using NHibernate.

Use SQLite C#: www.itwriting.com/.../...nning-in-silverlight.html

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.