First off, I love NHibernate. This tool has taken 30% to 50% off of project development.

But I keep agonizing over having bidirectional dependencies for all of my parent-child/one-to-many relationships. An example of this is described in http://nhibernate.sourceforge.net/nh-do ... /ch06.html. Bidirectional dependencies distort the domain model and increase coupling.

What can I do to avoid "Child" having a reference back to "Parent" in order to be saved? I know I can "allow nulls" for the "ParentID" in the "Childs" DB table and everything will work, but now I've weakened common data integrity practices (and the INSERT/UPDATE double call isn't very efficient). I suppose I could map a many-to-many relationship and store the relationship in a reference table (ParentID, ChildID), but now I've distorted the data model.

How can I effectively take advantage of NHibernate's cascading save-updates without relying on bidierectional dependencies?

Thank you!
Billy McCafferty

Alright, so I dug into Hibernat's documentation which actually recommends using a join table (a many-to-many) relationship when expressing a unidirectional, one-to-many relationship within the DB. Reference: http://www.hibernate.org/hib_docs/v3/re ... ional-join . That doesn't seem to make a lot of sense to me for a typical Parent/Child relationship.

Suppose "Child" is a composite element of "Parent." In other words, it doesn't make sense for Child to exist if Parent is removed. Mapping this relationally, the Child DB table stores a foreign key reference to the Parent. So the Parent cannot be removed unless the Child entries get removed with it. But setting up a join table implies that Child can exist without the parent and may, in fact, belong to multiple Parent objects; thus, distorting the data model.

Did I miss a new tenant of normalization that states that all Parent/Child relationships should be expressed via join tables?[/b]