Need help - interesting inheritance mapping problem...

komptaur · **Joined:** Thu Jan 10, 2008 11:33 pm **Posts:** 8

Hi all, I've been experimenting with NHibernate and want to achieve the following polymorphic inheritance structure:

I have an abstract type 'Item'. I have concrete sub-types of Item, such as MyItem or JoesItem. These are intended to be plugins, therefore I don't know the concrete type ahead of time. All Items will be placed into a List of type Item.

The database structure I have is like the table per subclass model, with a primary key on the superclass table 'Item' and an FK on the tables MyItem and JoesItem.

The problem is that, on retrieval, I don't know the type that will appear in the Primary Key (Item) table. I see the PK table holding something like:

ItemID | ItemType
1000, 'Me.MyItem,Me'
1001, 'Joe.JoesItem,Joe'

and then each subclass stores its data in its own table. I looked at the 'any' association, but my case seems different, as I have a PK table and the subclasses aren't associations but the thing itself.

I hope that NHibernate can map this association. Otherwise, any suggestions on how to break out of NHibernate at this point (this is part of a larger object hierarchy)?

Cheers!

mnichols · **Joined:** Mon Aug 21, 2006 9:18 am **Posts:** 179

For situations where you don't know the concrete type composition is better than inheritance. You can invert the hierarchy to decorate with Item...

komptaur · **Joined:** Thu Jan 10, 2008 11:33 pm **Posts:** 8

Thanks for the reply, mnichols, but I'm not sure I understand what you mean. I could create a decorator for an unknown concrete type like:

class Item
{

IItem real;

public Item(IItem realItem) { real = realItem; }
}

and expose the decorated IItem through a property (item.Plugin). Is that what you have in mind? I have shared properties/functions for some plugins, but not others, but I guess those would become 'normal' inheritance hierarchies.

Even so, I'm still not sure how NHibernate would be set up to retrieve the unknown types. In this case I would have no inheritance mapping in the database tables, correct? So how would I associate the plugin during Get operations?

Do you know of any good source (any language is fine) examples of a plugin architecture that uses decorators? My plugins aren't simple strategies. Rather, they expose interfaces specific to each individual plugin. They really are plugins to a container with some workflow and rules capabilities, and the ability to interact with other known plugin interfaces. E.g.,

interface IMyItem
{
void DoSomethingCool();
string Whatever { get; set; }
}

interface IJoesItem
{
void DoSomethingElse();
}

Thanks!

mnichols · **Joined:** Mon Aug 21, 2006 9:18 am **Posts:** 179

Here's one example of doing this but there lots of options...only one table it needed here:

Code:

public abstract class Item{   
   public void MyMethod(){
      //do stuff
   }
}

public class MyItem:Item{
   Item inner;
   public MyItem(Item inner){
      this.inner = inner;
   }
   public override void MyMethod(){
      inner.MyMethod();
   }
}

public class JoesItem:Item{
   Item inner;
   public JoesItem(Item inner){
      this.inner = inner;
   }
   public override void MyMethod(){
      inner.MyMethod();
   }
}

ItemTable
=========================================
Id   |   TypeCode   |   fk_innerItem_id
1      Base         null
2      My         1
3      Joes         1

   

komptaur · **Joined:** Thu Jan 10, 2008 11:33 pm **Posts:** 8

Thanks for the example, mnichols, I appreciate that. I see that I was turned around. You're decorating the Item with the subclass, rather than the other way around, as I was. It makes much more sense now.

Which leaves the question: What is the hbm mapping for this association? This isn't a single table inheritance model, as far as I can tell, so the TypeCode isn't a discriminator. If the 'any' association is used, I think I'd need to specify the whole type in the TypeCode column and add each possible plugin type to the mapping file... not sure what the nhibernate solution is here.

Thanks again!

komptaur · **Joined:** Thu Jan 10, 2008 11:33 pm **Posts:** 8

What I mean is, the problem doesn't lend itself to a single table inheritance model. I don't want to join against the one Item table as I don't know the extent to which that table would have to change to accommodate new properties on new plugins.