Geeks With Blogs
Billy McCafferty whatever (but really just .NET)

Suppose you have a “Project” object that has 0 or more “Attachment” objects in your domain.  (The Project class exposes an IList of Attachments and the Attachment has a reference to “ParentProject.”)  Now you'd like to introduce a new object called “Cabinet” which can also have a number of attachments associated with it.  (Cabinet also exposes an IList of Attachments.)  The question is, how do we manage the relationship via NHibernate and within the database so the attachment can be used by either Project or Cabinet and how does this affect the existing, one-to-many relationship between Project and Attachment?

To solve the problem you can

  1. Create subclasses, “ProjectAttachment” and “CabinetAttachment,“ and use the inheritance-mapping-strategy table-per-hierarchy using a discriminator.  You'd then change the Attachment listing within Project to contain ProjectAttachment objects.
  2. Create subclasses and use the inheritance-mapping-strategy table-per-subclass.  This ends up with three tables.  You'd also have to change the Project-Attachment as show in the first option.
  3. Create subclasses and use table-per-concrete-class.  This ends up with two tables.  You'd also have to change the Project-Attachment as show in the first option.
  4. Don't subclass Attachment but create two many-to-many join tables:  one between Project and Attachment and one between Cabinet and Attachment.

The first three options, along with their benefits and limitations, are discussed at http://www.hibernate.org/hib_docs/nhibernate/html/inheritance.html.  The forth is a simple trick to avoid having to create container subclasses that do nothing but act as a relationship place-holder for the Project-Attachment and Cabinet-Attachment relationships.  Obviously, if ProjectAttachment has different behavior than CabinetAttachment, then subclassing is the best solution.  But in many cases, you simply want the same object (e.g. Attachment) to be available to differen parent objects (e.g. Project and Cabinet).  In these cases, creating many-to-many relationships using join tables and maintaining the relationship from the parent object keeps the domain model devoid of place-holder classes that may otherwise clutter the code.

Billy

Posted on Monday, April 24, 2006 12:43 PM NHibernate | Back to top


Comments on this post: An alternative to "placeholder" Inheritance Mapping with NHibernate

# re: An alternative to "placeholder" Inheritance Mapping with NHibernate
Requesting Gravatar...
Hi, I don't get it how the 3rd option creates only two tables. Shouldn't it be 4 tables?

And some sample code would have been great.
Left by Buldozy on Dec 15, 2007 4:25 AM

# re: An alternative to "placeholder" Inheritance Mapping with NHibernate
Requesting Gravatar...
Hi Buldozy,

There would only be two tables: one for the ProjectAttachement object and one for the CabinetAttachment object. The 3rd option wouldn't have another table for the common fields.

The many-to-many relationship described in the 4th option is the easiest to setup and maintain, IMO; it is also more reflective of the domain.
Left by Billy McCafferty on Dec 17, 2007 11:34 AM

Your comment:
 (will show your gravatar)


Copyright © Billy McCafferty | Powered by: GeeksWithBlogs.net