Hi all,
I'm just starting my .NET studies and I got 2 questions:

1) Let's consider a product class. A product has an instance of a supplier object. OK. But when I list products, I don't want to see a supplier object, I want to see the supplier name. Because I can't render an object in a DataGrid for instance. Do you get it? But then I get a problem, because my product class would have to be adapted to bear a supplier name instead of a supplier object. So I guess I would need to write 2 classes. One full-OO, and other completely scalar so that I can render it. How can I do that automatically?

2) Now consider I have 450 queries in a very large system. the "format" of these queries will vary a lot. I Mean, sometimes I'll get a product, but other times I'll get a product with other columns embeded, all depending on the particular need of a query. It's not yet completely clear to me, how Hibernate deals with differences in query results. What if I need a Customer with an additional column? Do I need to create another BO to bear it? Can I return a query in a loosily-typed object? how does that work?

thanks a lot

You need to read some basic tutorials:
Try this for starters: http://www.hibernate.org/362.html

thanks but I've already read this tutorial and didn't help with my questions

I think i can answer some of this:

1) I don't think you will want 2 seperate classes as this would cause a lot of duplicate code for these types of situations. I think what you want is to be able to do a join between the product objects and suppliers. In HQL (Hibernate's query language) you want do do a fetch join. What this means is that you query for the products, with their supplier's property already pre-populated with supplier objects (as opposed to lazy loading it or retrieving it seperately.) Your query would look something like this:

Select p
from Product p
left join fetch p.Supplier

This tells NHibernate to get all the products and also populate their supplier properties in one query.

see this documentation:
http://www.hibernate.org/hib_docs/refer ... ryhql.html

After that, you can simply traverse your object model by doing something like: Product.Supplier.SupplierName or in asp.net you can render it to a page like this:

<asp:repeater runat="server" id="prodRepeater">
<itemTemplate>
Product Name: <%# Eval("ProductName") %><BR>
Supplier Name: <%# Eval("Supplier.SupplierName") %>
</itemTemplate>
</asp:repeater>

This works for most cases, the only downside is that when you do a join fetch, you are retrieving ALL the suppliers columns, because you're fetching the entire supplier object, even though you just want the supplier's name. In most cases though, it doesn't matter. I think there are other approaches as well, as HQL allows you to pull back scalars.

2) The short answer is going to be "it depends". You can use approaches like the above for simple things. For non-simple things, then you'll have to research HQL more, say for aggregates and so forth so you can get a mix of objects and scalar values, or maybe just scalars. I haven't done very much of this yet, so i'm not the best person to answer it. But you should check out the link and any documentation on HQL. It will probably do most of the things you need.

Hi Fregas, thanks for your reply. It was clarifying. Although I still have some questions:

1) One of our major concerns is GridView, because we develop data-driven applications in which the users must have a lot of control including custom sorting, pagination, grouping and more. The fact is that I used ObjectDataSource to expose the data retrieved by NHibernate to my DataControls, and I tried to access Product.Category.Name as a datafield inside my GridView. Of course I didn't get it and now I understand. That's why I created a scalar version of Product in the business layer. Actually I know now that the problem is not the datacontrol but the data source. Am I right? My data source must expose not only the Product properties but also the Category properties and so on, so that I can choose to show these properties in my GridView

I can be wrong, correct me if so.

Thanks again

I don't know if i'm completely following you. But let me give you a point of advice: Don't use the objectdatasource control with NHIbernate. Its not a good fit. MS designed the control with a very specific implementation of a business layer, and NHibernate doesn't fit that design too well. (I would say that NHibernate actually promotes a much more Object Oriented design, where MS promotes a more procedural one.) We had a lot of problems dealing w/ objectdatasource with any kind of O/R mapper (WORM, Castle or NHibernate directly.) Do the databiinding manually in the code behind, or find a custom datasource control specifically for NHhibernate (maybe some veterants can point us in the right direction.)

NHibernate + HQL can easily be used to do all the custom paging and sorting you would want, and i believe it does it all the the database server side to its more efficient then letting the gridview do it for you. For grouping i'm not sure. You may be better off using a dataset for that level of reporting, and keep nhibernate doing the CRUD and business logic stuff only. Again, I wouldn't make extra objects that have the extra fields that you want--you'll end up with lots and lots of extra "reporting objects" and introduce a lot of duplication which is almost always bad.

Hope this helps.

Sure that helps

You are not the first one to advice me that ObjectDataSource does not fit for NHibernate. It works mapping the CRUD operations to a business object, and it is productive because you can bind the parameters of these methods to visual controls, without coding. But I'm aware that, as long I need more flexibility then the 4 crud methods (for agregation in a grid for instance), we'll have problems. My problems lies 90% on how to integrate visual controls to NHibernate because the user interactivity is a major concern in my specific case.

Yesterday I came across a data source made specifically for NHibernate:
http://www.codeproject.com/useritems/NH ... Source.asp

To have my view tied to NHibernate is always an inconvenience because I don't trust NHibernate enough to say I'm not changing it tomorrow nor have I time to redesign my entire application in case it happens.

Besides this problem, it tightly couples the query to the view. Actually the query is written within the view what I cannot consider to do because I want reusability.

Considering that so many people use NHibernate in ASP.NET context. I wonder how do they expose it's data to the view, including GridView and Reports. I dream how great would it be if I could navigate my complex Product class as a tree, and choose exactly what properties to add as a column in a GridView :)

What data source to use so?

fregas, I really appreciate your attention.

I'm taking a look at
http://www.codeproject.com/aspnet/NHibe ... ctices.asp

the examples don't use any datasource bound to the view, I'm studing to see how did he use this approach and how productive would it be.

I use this with great success

http://vaultofthoughts.net/MyObjectData ... pdate.aspx

To be perfectly honest, I was not a big fan of using datasource controls at all. I tried them, but they seem to embed a lot of querying logic that should be in the code behind or possibly in the business/domain layer itself. Unless its something really simple, I tend to put my databinding logic on the code behind, which in turn calls methods on business objects.

Not sure if this will add any value or answer your original question, but I thought I would mention a few things. From the 2nd part of your original question, it seems to me that facing a problem that is common in ORM that the pros seem to understand but some us newbies have difficulty understanding. I encountered it when I had to implement a persistence layer using NHibernate and also to expose the persistence layer via Web Services.

One of the major problems I faced was differentiating between the actual object structure that correctly describes the model and allows NHibernate to do its job, and the objects that are actually exposed to the client; they don’t necessary have to be the same. Look at it more like your actual database tables and their relationships versus the database views; views are more or less the objects that clients or the UI want to see while the actual table structure and relationships are what NHibernate wants to see.

For correct persistence of all objects and their children you need to have the correct object structure if you want NHibernate to do the work. Querying the objects back to the client is where it can get interesting because you may have different result sets for different queries like you mentioned. Note that you may need to create additional classes (that are less complicated) that represent your views (result sets) in addition to your persistence objects.

This approach worked for me because my savings involved more complex and larger objects than when I was querying the data. And since I was sending data across a web service, I was also concerned about sending entire order with all its children every time the client queries an order. I ended up having separate mappings for persistence and querying. I created persistence classes (for saving) and view classes(result sets) and mapped them separately. I ended with more classes, but it saved me a lot of pain and frustration. The advantage I gained was more granular classes, easy to manage, could mess with the persistence classes without affecting the view classes, plus, more. Not sure if this is the best approach but it worked for me and my implementation is in production right now and performing wonderful.

fregas, that's right but not necessarily. ObjectDataSource works mapping a the CRUD operations to a business layer. But I think it a little limited.