Hi, I was wondering what is the best practice you have found to map a strategy. Suppose you have an object Foo that can have a relationships to a stretegy from a family.

One way would be to map to in a private field the Stretegy class name and instantiate it in runtime using reflection. Another would be to use a new table with table per hierarchy. This table seems a bit awkward since it will only have an ID and a class discriminator. Finally I guess there must be other options that I haven't considered yet.

Any thoughts??

Another possibility is to create a user type which knows how to map an integer column to strategy instances. The problem with this approach is that the mapping is hard coded in the user type.

Or map a class name to a strategy instance, that way you won't have to hard code anything.

Actually, even if you go with table-per-hierarchy, I think you may need to store strategy "configuration options" later on, and the table might become a good place for those.

All of our entities have an associated strategy object, since our entity classes themselves contain only generated code.

We have an entity factory that keeps a dictionary of entity and strategy types to instantiate, given the class name only (replacements must preserve the class name -- i.e. the namespace and assembly must be different). Actually, for each type (entity or strategy), a stack of overriding types is kept, with each override in a given stack associated with a "customization layer". This allows customization layers to be enabled, disabled, added, etc. For entity types, the "top" override on its stack must be kept in sync with the assembly-qualified entity type name defined in the NHibernate mappings (*.hbm.xml files). Our entity generator / customization layer management utility assures this.

Our entity factory and our NHibernate interceptor then simply instantiate and attach the "top override" strategy class to all entity instances they provide.