[NHibernate] mapping van interfaces en hun implementors

[H!GHGuY]

Ik heb volgend klasse diagram:


Zoals je kan zien kan een Project uiteindelijk andere Projects and Tasks bevatten, mooi volgens het composite pattern. Daarnaast kan een Task dependencies hebben die dan weer Projects, Tasks of Events zijn. Nu wil ik dit ook in Nhibernate mappen. Voor ik de code schrijf had ik graag geweten welke strategie ik het best toepas.

De table-per-class-hierarchy valt meteen af. De not-null beperkingen en de bloated tabel maken deze een no-go.
Table-per-subclass lijkt me 1 van de logische keuzes. Inheritance wordt wel vaker op deze manier uitgedrukt.
Ik hou dan wel een primary-key table over met 1-to-1 relations met de subclass tables.
Table-per-concrete-class lijkt me ook een mogelijke keuze, maar ik heb bedenkingen bij de <any> mapping die nodig is om zo'n class te refereren.

Als ik nu table-per-subclass kies, dan zie ik niet meteen hoe ik de primary keys moet managen. Zowel IDependency als ITask kunnen primary keys geven aan de subclasses, maar kan IDependency dan ook aan ITask keys geven? En gaat NHibernate dan ook goed om met de keys van de subclasses Task en Project?

Ook zijn er vormen die van impliciete mappings gebruik maken maar het is me niet duidelijk of ik dan in de Project klasse zowel een container voor Projects als voor Tasks moet bijhouden.

[whoami]

Hoe bedoel je, de PK's managen ?
Hoe zou je DB schema er ongeveer gaan uitzien ?

In je Project class zou je een container kunnen bijhouden van ITask instances. (Task implement ITask, en Project blijkbaar ook).

[H!GHGuY]

Ik ben van plan om NHibernate mijn DB schema te laten maken, dus an sich maak ik me daar geen zorgen over, alleen moet ik dit nog kunnen uitdrukken in een Nhibernate mapping file.

Volgens table-per-subclass krijg ik zo'n chain:

code:

Tabel Dependencies (IDependency)
  ID (PK)
Events (Event)
  ID (PK/FK) met 1-to-1 mapping naar Dependencies
  Rest data
ITasks (ITask): 
  ID (PK/FK) met 1-to-1 mapping naar Dependencies
Task (Task):
  ID (PK/FK) met 1-to-1 mapping naar ITasks (en dus ook Dependencies)
  Rest data
Project
  ID (PK/FK) met 1-to-1 mapping naar ITasks (en dus ook Dependencies)
  Rest data

Mijn hoofdvraag is dus of die dubbele interface inheritence van Task/Project -> ITask -> IDependency kan uitgedrukt worden in de NHibernate mapping en of de table-per-subclass wel de juiste keuze is.
Zeker als je rekening houdt met het feit dat een Task dependencies heeft die Tasks, dan wel Projects dan wel Events zijn. Daarnaast is er ook de collectie van Project die zowel Projects als Tasks kan bevatten. Ik moet dus beide niveau's kunnen queryen. Ik wil dus weten hoe ik NHibernate deze polymorfe lijsten het best laat aanpakken.

Ook even een foutje rechtzetten: In mijn klassendiagram moeten beide composities eigenlijk aggregaties zijn...

[ Voor 4% gewijzigd door H!GHGuY op 08-06-2009 19:36 ]

[H!GHGuY]

Niemand met enige advanced kennis van NHibernate ?

[dotcode]

Volgens mij heb je maar 2 tabelen nodig, namelijk Task en Event waar bij een 1 op n mapping van Task naar Event en een relatie tussen tasks om projecten te kunnen opslaan.

[H!GHGuY]

Ik heb ondertussen ook al zitten nadenken of ik mijn klassen niet wat moet bijwerken om dit makkelijker te maken. Het probleem is hier echter dat Project vooral dienst doet als collectie van ITasks. Als ik Task en Project in 1 klasse stop dan krijg ik overal if-then-else logica. Ik ga dus op OO vlak achteruit ipv vooruit.

Hopelijk is dit wat je bedoelt?
Of wil je zeggen dat ik Task en Project in "table-per-hierarchy" moet zetten?
Het probleem blijft dan natuurlijk dat Projects en Tasks ook dependencies kunnen zijn. Dus die 1-n mapping van Task naar Event dekt niet de volle lading.