I love NHibernate, but something has been bugging me. There is no way for a parent to intercept events on a child collection (no SetChanging event on the Iesi Set). As a result, objects can get into invalid states. I thought that the point of having BO's was so that they could ensure that they're state was always valid. Consider the following case:

An Area object has a set of child Zones. Each zone must have a unique number within the Area's collection. A client object adds a Zone object with a number of "3" to an Area's Zone set. The Area's Zone set already contains a Zone with a number of "3". The state of Area is now inconsistent.

How can I avoid this problem? I've tried wrapping the set in my own set with events, which works but it's tricky making sure that all the events are properly attached and detached. Is this the recommended method? Should I be validating this stuff when updating the Area object?

Don't let Area's clients modify Area.Zones directly, but instead create a method like AddZone/RemoveZone and do any checks inside the method. It is possible to map a private property or a field with NHibernate.

That doesn't strike me as an entirely satisfactory solution as I have to duplicate all the the ISet methods (proceeded by the name of the collection I guess) in the parent object like so:

Customer::AddOrder
Customer::RemoveOrder
Customer::ContainsOrder
Customer::...


Don't misunderstand me, I appreciate the help and this would definitely work, I'm just wondering why this is a better idea than wrapping the ISet with a new Interface IObservableSet which fires events when something is _about_ to be done, allowing any listeners (ideally only the parent object) to throw an exception if something illegal is about to happen. Is there some reason why this would cause problems for Hibernate? Are there any obvious problems with this approach (such as Hibernate not being able to serialize objects)?

All of our collection properties on our entities are publicly exposed as strongly typed. The collecction properties (actually, all of our properties) are mapped with field access, so exposing the actual property with a different type doesn't bother NHibernate (it never accesses the property). These types implement the appropriate .NET collection interface (IList, etc), keep the NHibernate collections internally, expose events such as ItemAdding, ItemAdded, ItemRemoving, ItemRemoved, etc. The collection property's getter lazy-initializes the strongly typed collection (the entity must keep both the stronly and weakly typed collection as separate fields), and passes the owning (parent) entity, item's parent property name, and weakly typed collection-to-wrap to the constructor. The Add/Remove methods automatically set/clear the item's parent property.

This has worked out well so far, since our typical entity has at least 3 or 4 collection properties, and some have over a dozen. It would be ridiculous (and horribly non-OO) to put AddXXX and RemoveXXX methods on the parent entity for every collection property.

Not really, you can use a wrapper class such as ImmutableSet that would prevent anybody from modifying the collection, while still allowing to do other operations. There is a similar wrapper for ILists (call ArrayList.ReadOnly), but I don't know of one for IDictionaries.