Abraham

maandag, 30 augustus 2004
In een 3-tier architectuur staan de lagen los van elkaar. De data laag doet bijvoorbeeld als enige SQL, compleet los van de objectenlaag. Die onafhankelijkheid is wel vrij algemeen geaccepteerd. De implementatie van zo'n scheiding is lastiger.

DataRetreiver:Tabel = 1:1?

Veel automatiseerders maken per tabel een data object, één op één. Dat is jammer.

Object:Tabel = 1:1?

Het kan nog een graadje erger: Business objecten één op één met de tabellen, want dan is alles zo mooi consistent.

Wie het verschil weet tussen de halfbroers Class en Tabel kent, ziet hoe onzinnig zo'n 1:1 is. Als neveneffect hoor je de irrelevante discussies tussen OO-ers en data-ologen al weer oplaaien. Dat de halfbroers een conceptueel model gemeenschappelijk kunnen hebben, lijkt iedereen vergeten.

De model->tabel mapping verschilt van model->class mapping. Dat verschil moet blijven. Poets die verschillen weg en er blijft geen reden meer over voor de verschillende lagen.

Hoe blijven de lagen wel onafhankelijk?

Heel simpel:
  1. Maak 1 grote data class en noem hem bijvoorbeeld Abraham.
  2. Business objecten roepen de juiste, encapsulated method aan, zonder te weten waar en hoe Abraham de mosterd haalt.
  3. De data laag geeft ruwe data terug. Voor SQL kan dit een result set zijn, met afgesproken aliasses voor elke kolom. Uit welke kolom/tabel de data werkelijk komt is dan voor de business laag niet meer van belang.
  4. De business laag vertaalt die ruwe data in objecten, mogelijk van verschillende classes.
De data laag kan dan veranderen, zolang het contract met de business laag maar niet verandert.

Het is bijvoorbeeld mogelijk om, onzichtbaar voor de objectenlaag:

Wie de ene Abraham kent komt aan mosterd, maar weet niet waar Abraham de mosterd vandaan haalt. Dan zijn de lagen echt onafhankelijk van elkaar. Dat is mooi, dan kan Abraham nog eens ergens anders gaan inkopen zonder dat zijn klanten het merken.

Tot de volgende noot,
Henk Jan Nootenboom