I read this question here on code project, and note that it doesn't have an answer. I have the same question

http://www.codeproject.com/aspnet/NHibe ... x1810733xx
(question titled Upgrade to NHibernate 1.2.0 - Add/Remove Scaffolding)


When using NHibernate.Generics, it provided a useful method for wiring up entity relationships when adding a child object to a collection on the parent. Now that it is no longer really necessary to use NHibernate.Generics with 1.2 supporting .NET generics, is there a good way to implement this same functionality? What is the best way to wire up these types of relationships so that adds/removes work properly??

NHibernate.Generics is deprecated not only because 1.2 has native generics support, but because I found that the auto wiring led to much confusion down the road.
I suggest that you will use the recommended way of adding:
AddXYZ() to handle this.

Ok, I thought I had this sorted, but it appears not, and I thought it was simple, so I'm finding it a bit frustrating wiring up these entities.

I've implemented the approach discussed by jnapier in this thread here:
http://forum.hibernate.org/viewtopic.ph ... c&start=15
to use a custom list implementation with events on the Add and Remove methods to ensure that parent relationships are set up when the child is added to the collection. I'm still not entirely clear on how to manage the relationship when the child is added to the parent.

i.e. the scenario:



works fine, because the event that gets triggered on the add has the code for child.Parent = this;
However, when I come from the other direction, if I do:



and then in the setter for child.Parent do something along the lines of:



I get a LazyInitializationException : cannot access loading collection.

What's the (or a) right way to manage a bidirectional parent/child relationship that will be used from both directions?

Anyone? Is this just waaay too obvious and I'm barking up the wrong tree?

You should avoid putting logic in the property accessors that NHibernate uses because you can't really predict what will be the object state when NHibernate calls them. The best way would be to have a separate method, Parent.AddChild(Child) that wires both instances together appropriately.

Thanks for the reply, however I don't think I have a problem with the parent.AddChild(child). My problem is when I call child.Parent = p (or similar).

When I try to set the parent on the child, I have to add the child to the parent's children collection, and it is at this stage that I am getting the LazyInitializationException.

I was under the impression that I had to manage the association from both ends - i.e. when wanting to add a child to the parent I have to do:

this.children.add(c);
c.parent = this;

but also the other way around:

p.children.add(this);
this.parent = p;

The first is handled ok currently, the second is causing issues. Should I not be using lazy="true"? should I not be using a bag?

You should avoid putting logic in the property accessors that NHibernate uses because you can't really predict what state the object will be in when NHibernate calls them.

Or use access="field.somenamingstrategy".

Thanks for your help - sorry it took me a while to understand :)

The problem we've found with this approach is that collections mapped as IList exposes Add/Remove methods which don't maintain bi-directionality. For that reason, we've created a IReadOnlyCollection interface:



and a base class implementation.

Then we are able to derived custom collection classes with custom add/remove methods as required. It's more work, but results in a more elegant and intuitive design.