I'm scratching my head trying to figure out how to map this mess of a
hierarchy. This is a six-table hierarchy with parent, parent-to-child linking
table, and four child tables in a poorly attempted one-to-one mapping.
Parent
Id (int identity)
Link
Id (foreign key to Parent.Id)
ChildType (enum 1=ChildA, 2=ChildB, 3=ChildC, 4=ChildD)
ChildA
Id (foreign key to Link.Id)
ChildType (foreign key to Link.ChildType, constrained value must be 1)
ConcreteTableB
Id
ChildType (constrained value must be 2)
ConcreteTableC
Id
ChildType (constrained value must be 3)
ConcreteTableD
Id
ChildType (constrained value must be 4)
This hierarchy is riddled with issues:
1. Parent.Id is an identity key that has to be replicated into Link.Id and
Child[A-D].Id. I think this means I'll have to manually replicate the identity
key into the link and child classes. It's ugly but I don't really see a good
clean way to handle it.
2. Only one of the child types can be instantiated for any parent. In other
words, if Link.ChildType=1 the only class that can be assigned to Link.Child is
ChildA. The developer and DBA that created this mess years ago claims the
parent-to-child linking table allows creating only one child type but the
primary key/foreign key relationships blow that theory right out of the water.
3. Most of the fields in each child class are identical... code reuse via the
copy-paste method apparently. If possible, I would like to handle the shared
fields in an abstract base class with a class structure as follows:
public class Parent
{
public int Id { get; set; }
public Link Link { get; set; }
}
public class Link
{
public int Id { get; set; }
public ChildType ChildType { get; set; }
public Child Child { get; set; }
}
public abstract class Child
{
public int Id { get; set; }
public ChildType ChildType { get; set; }
// blah blah
}
public class ChildA : Child
{
// blah blah
}
The relationship from Parent to Link seems to be a relatively simple
References(x => x.Link) with some backing code in the repository/DAO class that
replicates the primary key into the subsequent tables on save. If anyone has a
better idea, I'd love to hear it.
Where I'm mostly stuck is how to map the child classes. I thought about perhaps
trying to use a discriminator with a table-per-class relationship, but I'm not
certain this is the right approach in this case.
My first thought of course was to recreate the table schema but I found too
many external dependencies for this to be feasible at this point. My primary
goal at this stage is to replace some of legacy apps using these tables with
something more domain-driven. Maybe next year after we've migrated the core, we
can investigate replacing some of the schemas with schemas that are easier to
map and use.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibernate@googlegroups.com
To unsubscribe from this group, send email to
fluent-nhibernate+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
