T-model

maandag, 4 oktober 2004
Deze vragen waren afgelopen week actueel tijdens een project bespreking met Sara Borremans.

3 lagen model

Een drie lagen model lost veel van dit soort vragen op, maar niet alle.
User interface laag
Logica in Business objecten
Persistency in Data laag
In de GUI laag zit een beetje logica die het liefst niet bij de GUI specialist thuis hoort:
  1. Request routing naar de juiste actie.
  2. Acties uitvoeren aan de hand van binnengekomen request parameters.
De GUI specialist zou zich volledig moeten kunnen focussen op de lay out. Het is moeilijk genoeg om een grafisch aantrekkelijk geheel te maken, wat ook nog prettig werkt. Dat is een vak apart, moeilijk genoeg. Laat een ander zich concentreren op de logica, ieder z'n specialisme.

T-model: RAD, ALP

Om de GUI logica te scheiden van de lay out krijgt de GUI laag drie gedeeltes. Het drie lagen model wordt daarmee een T-model, met 3 stukken in de GUI: R, A, D.

R, Request Routing

Wat moet er gebeuren, welke actie? Moet de gebruiker nog inloggen of kan een actie uitgevoerd worden?

A, Actie

Zijn de request parameters valide? De actie spreekt de objectenlaag aan om gegevens controleren, op te halen of te wijzigen.

D, Display

Wat krijgt de gebruiker als resultaat op het scherm? Dit is het domein van de GUI specialist, die met de grafisch ontwerper overlegt over de precieze lay out.
 

L, Logica

De business objecten voeren de logica uit, op verzoek van de actie.
 

P, Persistency

De data laag slaat gegevens persistent op in een database, bestand of interface met een ander systeem.
 
Het stuk rechtsboven kan lean & mean blijven. Iedere specialist kan zich focussen op het eigen werk met minimale impact op het werk van de anderen. De grafisch specialisten kunnen een nieuwe lay out introduceren, zonder impact op de overige code.

Interesse of deze architectuur met het T-model ook voor uw situatie kan werken? Neem contact op.

Tot de volgende noot,
Henk Jan Nootenboom