storing decorated objects

derhackler · **Joined:** Mon Mar 05, 2007 5:52 am **Posts:** 2

Hibernate version:
1.2.0

First of all: Thank's a lot for the great product! I'm just starting using it but so far it works great.

But there's a little problem anyhow:

After retrieving objects I decorate them based on some business logic (see decorator pattern). The decorated objects behave exactely the same then the original objects but have some additional methods. When I try to store the objects I get the exception:

Code:

Unknown entity class: ....ClassName

Of course the decorators aren't mapped in the configuration and I don't want to do that as it would add a huge amount of dublicated mappings.

A possible solution would be a change in the GetEntityPersister(Type) in SessionFactoryImpl.cs:

Instead of:

Code:

      public IEntityPersister GetEntityPersister(System.Type theClass)
      {
         IEntityPersister result = classPersisters[theClass] as IEntityPersister;
         if (result == null)
         {
            throw new MappingException("Unknown entity class: " + theClass.FullName);
         }
         return result;
      }

I would use:

Code:

      public IEntityPersister GetEntityPersister(System.Type theClass)
      {
         IEntityPersister result = classPersisters[theClass] as IEntityPersister;
         if (result == null)
         {
                if (theClass.BaseType == null || theClass.BaseType == typeof(object))
                {
                    throw new MappingException("Unknown entity class: " + theClass.FullName);
                }
                else
                {
                    return GetEntityPersister(theClass.BaseType);
                }
         }
         return result;
      }

If the mapping of a class isn't found if would try to find the mapping of the base class recursively.

Do you think this is a viewable solution?
Does it have any known side effects?
Should it be something in the core?
Should it be a behaviour that can be set in a config file?

Thanks in advance for your answers.

benedikt

radu · **Joined:** Wed Jun 15, 2005 4:17 am **Posts:** 156

Do you have control over the database? If yes I would suggest you to map the whole class hierarchy using the table per hierarchy mapping strategy.

Radu

derhackler · **Joined:** Mon Mar 05, 2007 5:52 am **Posts:** 2

thank's for your answer, but this wouldn't solve my problem. I'm using decorators primarily for adding behavioral aspects to my objects and they therefor can't and shouldn't be mapped to tables.

benedikt

.ben · **Joined:** Tue May 02, 2006 8:04 am **Posts:** 34

I've got the same problem. I use Spring.NET to create proxys in my presentation layer to add some UI behaviour to the objects (propertychanged etc.)

Anyhow, I think it's on the Jira: http://jira.nhibernate.org/browse/NH-662

david.joyce13 · **Posted:** Wed Jun 06, 2007 4:53 pm

derhackler wrote:

I'm using decorators primarily for adding behavioral aspects to my objects and they therefor can't and shouldn't be mapped to tables.

I have the same situation. I have looked at the different inheritance strategies again - having used most of them at some point in the past - and I don't think any of them quite cover the situation created by the GoF Decorator Pattern, which is really about adding or modifying behavior at runtime... it's not about state.

It seems that table-per-subclass comes closest, as it establishes a one-to-one relationship between the subclass and the base parent class.