Nøglebegreber
Bemærk i Figur 1-2, at hvert af lagene i arkitekturen er markeret som værende lukket. Dette er et meget vigtigt begreb i det lagdelte arkitekturmønster. Et lukket lag betyder, at når en forespørgsel bevæger sig fra lag til lag, skal den gå gennem det lag, der ligger lige under det, for at komme til det næste lag under det pågældende lag. F.eks. skal en forespørgsel, der kommer fra præsentationslaget, først gå gennem forretningslaget og derefter til persistenslaget, før den endelig når frem til databaselaget.
Figur 1-2. Lukkede lag og adgang til forespørgsler
Så hvorfor ikke give præsentationslaget direkte adgang til enten persistenslaget eller databaselaget? Direkte databaseadgang fra præsentationslaget er trods alt meget hurtigere end at gå gennem en masse unødvendige lag, bare for at hente eller gemme databaseoplysninger. Svaret på dette spørgsmål ligger i et nøglekoncept, der kaldes lag af isolation.
Isolationslagskonceptet betyder, at ændringer, der foretages i et lag af arkitekturen, generelt ikke påvirker eller påvirker komponenter i andre lag: ændringen er isoleret til komponenterne i det pågældende lag og muligvis et andet tilknyttet lag (f.eks. et persistenslag, der indeholder SQL). Hvis man giver præsentationslaget direkte adgang til persistenslaget, vil ændringer i SQL i persistenslaget påvirke både forretningslaget og præsentationslaget og dermed give en meget tæt koblet applikation med mange indbyrdes afhængigheder mellem komponenterne. Denne type arkitektur bliver så meget svær og dyr at ændre.
Begrebet lag af isolation betyder også, at hvert lag er uafhængigt af de andre lag og dermed kun har ringe eller ingen viden om det indre arbejde i andre lag i arkitekturen. For at forstå styrken og betydningen af dette koncept kan man tænke på en stor refaktoriseringsindsats for at konvertere præsentationsrammen fra JSP (Java Server Pages) til JSF (Java Server Faces). Hvis man antager, at de kontrakter (f.eks. model), der anvendes mellem præsentationslaget og forretningslaget, forbliver de samme, påvirkes forretningslaget ikke af refaktoriseringen og forbliver fuldstændig uafhængigt af den type ramme for brugergrænsefladen, der anvendes af præsentationslaget.
Selv om lukkede lag letter isoleringslag og derfor er med til at isolere ændringer inden for arkitekturen, er der tidspunkter, hvor det giver mening, at visse lag er åbne. Lad os f.eks. antage, at du ønsker at tilføje et lag med delte tjenester til en arkitektur, som indeholder fælles tjenestekomponenter, der tilgås af komponenter i forretningslaget (f.eks. data- og strengværktøjsklasser eller revisions- og logningsklasser). Det er normalt en god idé at oprette et servicelag i dette tilfælde, fordi det arkitektonisk set begrænser adgangen til de fælles tjenester til forretningslaget (og ikke til præsentationslaget). Uden et separat lag er der intet arkitektonisk, der begrænser præsentationslaget i adgangen til disse fælles tjenester, hvilket gør det vanskeligt at styre denne adgangsbegrænsning.
I dette eksempel vil det nye servicelag sandsynligvis ligge under forretningslaget for at angive, at komponenter i dette servicelag ikke er tilgængelige fra præsentationslaget. Dette giver imidlertid et problem, idet forretningslaget nu skal gå gennem servicelaget for at komme til persistenslaget, hvilket slet ikke giver mening. Dette er et gammelt problem med lagdelt arkitektur, og det løses ved at skabe åbne lag i arkitekturen.
Som illustreret i figur 1-3 er servicelaget i dette tilfælde markeret som åbent, hvilket betyder, at anmodninger har lov til at omgå dette åbne lag og gå direkte til laget under det. I det følgende eksempel, da servicelaget er åbent, er det nu tilladt for forretningslaget at omgå det og gå direkte til persistenslaget, hvilket giver god mening.
Figur 1-3. Åbne lag og forespørgselsflow
Anvendelse af begrebet åbne og lukkede lag hjælper med at definere forholdet mellem arkitekturlag og forespørgselsflow og giver også designere og udviklere de nødvendige oplysninger til at forstå de forskellige lagadgangsbegrænsninger i arkitekturen. Hvis man undlader at dokumentere eller kommunikere korrekt, hvilke lag i arkitekturen der er åbne og lukkede (og hvorfor), resulterer det normalt i tæt koblede og skrøbelige arkitekturer, der er meget vanskelige at teste, vedligeholde og implementere.