Hi..

I see that with inverse=true on my bag, there is efficient fetching of my IList collection.

But I like to have another IList collection on the items of the first IList collection.

Like this:

doCompanies have doBranches which have doDepartments

All three have corresponding tables in the database.

When I do this and Load a doCompany, the doBranches are fetched pretty efficient,
but then there will be a query for each Branche to load the Departments..

I use a Bag in Companies and Branches and a many-to-one on Branches and Departments.

Is there a way to tell nHibernate, to load all Departments based on CompanyID using a join with Branches and then sepperate the objects on the clientside?

Or am I totally missing the point why to use nHibernate?

Already a big thanks, for those who try to help me out..

Well, what you state can be done relatively easily with a central IList<doDepartment> allDepartments in your doCompany. That will allow you to define a single list mapping for allDepartments in your doCompany HBM file. It doesn't matter that it's private, as long as you tell NHibernate to access it as a field using the proper naming convention (i.e. lower camelcase). Once you have it, it should be a matter of using a lambda delegate and/or some Linq extensions to grab a list of Departments for each branch.

However, I do think you're missing the point slightly. The point of NHibernate is that you can simply tell it to hydrate an object graph and it does so. To hydrate Departments directly from the Company, without NHibernate being able to do so Branch by Branch, requires that you always hydrate a Branch in the context of a Company. That means you always need the entire Company object graph. It also means you're always "eager-loading" all Departments when hydrating a Company, even if all you need from the object is a simple value property or child object (or the Departments of another Branch).

Thanks Liko,

About your solution to add a global department list in my doCompany..

I'm not sure how to do that, does it imply that my table Departments will need a extra foreign-key to Companies, in addition to the BrancheID key it has now?

How am I otherwise going to map it?

About me missing the point slightly..

Your probably right, it just does what it's supposed to do.

I just expected that since I defined enough attributes for nHibernate to know the structure of my OO and DB model, that it would do some smart optimization.

I thought this, since my example is pretty much the simplest use I could think of, when using a framework like this.

But again, my knowledge is so far not sufficient to oversee it completely.

I believe nHibernate is so flexible in it's features, you simply have to pick a good strategy and don't expect nHibernate to solve every problem you came across when we learned to do it the old fashion way..

Understanding this new framework is so far the biggest plunch into the deep, I have ever experienced over my decade of software development activities.

We could use more good, practical in depth tutorials :-)