Domain model: inheritance vs composition

[Verwijderd]

Het volgende probleem zullen jullie allemaal wel kennen:

Je het je domain model en dit domain model moet pesistable gemaakt worden dus moet er een id, version en meestal nog een creation en modification date op.

Nu zijn er dat ik weet 3 methodes met alle 3 hun voor en nadelen.

De eenvoudigste is gewoon een abstract class PersitableObject maken en uw domain die laten extenden.

De 2de mannier is via compostion en een interface waar je domain een object PersitanceProperties heeft en een interface Persitable implementeert. Dit is veel flexibeler dan de vorige oplossing, maar vereist het schrijven van delegate methodes en is moeilijk te mappen als je ejb3.0 gebruikt.

De 3de is de meest complexe. Bij de vorige 2 methodes zie je nog altjd aan je model dat het naar een databank wordt geschreven. Een oplossing hier voor is om een PesistableWrapper te schrijven rond je domain object. Maar dan heb je voor iedere domain class een domainInterface, domainImpl en domainWrapper nodig.

Welke methode verkies jij en waarom?

[whoami]

Wat is volgens jou het voordeel van de 3de methode ? Ik zie bij 3) enkel meer werk.

En hoe zie je de 2de methode precies ?

Je kan natuurlijk ook gewoon gebruik maken van een O/R mapper, zoals Hibernate, die alles mbt persistentie voor jou uit handen neemt.

[ Voor 9% gewijzigd door whoami op 15-04-2006 11:40 ]

[Verwijderd]

Ejb3.0 neemt ook alles van persistance uit handen maar je moet nog altijd de nodige velden(id,version) voorzien op je object.

De 3de methode is inderdaad veel werk, maar heeft 1 voordeel uw model blijft volledig vrij van persitance code. Het domain zelf heeft niets aan een id en een version, die zijn er alleen omdat je ze wil opslagen in een databank. Dus als je domain echt onafhankelijk wil maken van het feit dat ze worden opgeslagen in een db dan is methode 3 denk ik de enige oplossing. Methode 3 zou ik ook niet snel toepassen van wegen haar complexiteit.

Methode 2 is vrij eenvoudig.

Je hebt :

class PeristanceProperties{
Long id;
Long version:

getId(){code}
getVersion(){code}
setId(Long id){code}
setVersion(Long version){code}
}

interface Peristable{
getId();
getVersion();
}

class myDomain implements Peristable{
PeristanceProperties peristanceProperties;

getPeristanceProperties (){code}
setPeristanceProperties(PeristanceProperties peristanceProperties){code}

getId(){
peristanceProperties.getId()
}

getVersion(){
peristanceProperties. getVersion()
}
}

Deze methode is wat meer werk dan met inheritance maar je hebt alle voordelen polymorpism zonder de nadelen van het extenden. Het geen wat mij momenteel tegenhoud om methode 2 te gebruiken is dat ik in ejb3.0 nog geen mannier heb gevonden om deze stuctuur op een degelijke te mappen

[EfBe]

Volgens mij is methode 1 de meest pragmatische. De andere 2 en met name 3, komen neer op het creeeren van extra werk zonder dat men daar extra voordeel van heeft. Methode 1 houdt nl. ook in dat het niet hoeft dat de classe een 'Save' method heeft, maar bv dat de class de interfaces e.d. van methode 2 al implementeert.

Bij projects die een jaar of langer lopen, met vele vele tables en classes, daar is men echt niet gebaat bij clean-room oplossingen die gefocussed zijn op het abstract maken van zoveel mogelijk zaken 'omdat dat wellicht nuttig kan zijn'. Men moet zn tijd steken in wat nuttig is voor het project, niet wat nuttig is voor een situatie waarin men zich niet bevindt.