I have seen a ton of questions regarding the same issue when it comes to nHibernate and Winforms.

Winform development is significantly different from Java Web App development. And with the release of .Net 2.0, ASP.Net web development is moving closer to Winform development.

Both targets have a set of "Data Aware" UI controls that rely on the DataSet to feed them. Does nHibernate support retrieving DataSets from HQL queries?

Is there a way for nHibernate to support implementing a Data Provider
http://msdn.microsoft.com/library/defau ... ovider.asp

This is the path the team SHOULD take if they want to make this more than just a port of Java Hibernate to C#.

In .Net 2.0 both Windows and Web forms support binding to objects and custom collections.



I disagree. NHibernate is designed to support an MDA and Object centric approach to development. Datasets and their usage are generally a very data-centric approach.

If you want a dataset based O/R M take a look at Deklarit. Or course it is not open source.

BOb

Yes but behind the scenes all the "object binding" is really doing is creating a strongly typed DataSet.



There is nothing wrong with nHibernate supporting an Object centric approach. However, "When in Rome, do as Romans do." Why ignore the RAD advantage that the DataSet brings to App development on the .Net platform because it's not done that way in Java? It's not that nHibernate would even have to do things differently behind the scenes, we just add a DataProvider wrapper (Adapter pattern) around what's already there. That way, a developer can choose which approach to use. And for advanced developers who want to take advantage of the power of a rich domain model while still enjoying the luxury of datasets for presentation, they can enjoy the best of both worlds.

I've actually started the process of developing a DataProvider Adapter for nHibernate. It's a lot easier to demonstrate what I mean with working code than with words.

I don't have access to the .NET 2.0 framework sources but I can honestly tell you that when binding objects (or collections of objects), no typed datasets are created automagically. The data-aware controls are looking for specific interfaces (Winforms, with ITypedList and IBindingList) or use reflection to do the databinding.

I am not against providing support for Dataset... And I am already thinking about it.

Will you release your DataProvider Adapter for NHibernate?

I definitely will be releasing the Adapter. I'm going to start by implementing IDBDataAdapter. So far I don't see a need to any extensions to the Mapping files to support this.

The first goal is to make a non-invasive layer that uses the Hibernate APIs to implement the appropriate interfaces.

After getting that working properly, I will look at non-breaking changes to the libraries themselves that can optimize the use of the IDataAdapter (eg keeping DataSets in the Cache so that updates don't have to go through the effort of translating from a DataSet back to the object graph). This may involve extensions to the mapping files.

Another route I'd like to explore is using dataset schemas (as generated by VS) to generate nHibernate mappings or using them natively within nHibernate.

On another note, I've seen an excellent example of using the DSL (Domain Specific Language) tools to create a graphic editor for Spring.Net configurations. I think this can be something useful for nHibernate as well.

Sorry if I'm firing off too many ideas at once. If I don't put them in writing somewhere, they'll be forgotten quickly.

I don't see the problem....

(N)Hibernate is an ORM (Object Relational Mapper).
So, it means, it works with objects. It is able to persist objects to a relational model, and get data out of a relational model, and put it into objects.

I don't see why nhibernate should support datasets, since, this is a complete other way of working ?

(N)Hibernate 's goal is, imho, to be able to work with a 'domain driven' business logic layer; so, your business objects are objects, and not dataset / datatables.
NHibernate is here to free the developer of glue-ing his domain model with the database.

If you want to work with dataset/datatables, then, you should not be working with nhibernate.
You should use the right tools, for the right job.
If you want to work with domain-objects, use hibernate, or another ORM tool that provides the mapping between objects and rdbms.
If you want to work with dataset/datatables, then, you should use another kind of tool.

Hi

A bit offtopic (maybe).

But the default session implementation are very nice to work with when you are doing asp.net but it feels like it doesnt suit winforms.

Shouldnt it be possible to replace the current implementaion of the session to something that will suit winforms development better.

Im not sure if this is the correct or if its even doable. But I dont like to add code in my poco's when i need to reuse them in a winform application, and I dont want to remove code.

This just a feeling i have had for some time now.

Well, nothing is white or black... If we can provide support for Dataset without breaking the current architecture, then I think that it is a good thing.

I move this topic to "Related Projects"...