Key Concepts
Bemärk i figur 1-2 att varje lager i arkitekturen är markerat som stängt. Detta är ett mycket viktigt begrepp i det skiktade arkitekturmönstret. Ett stängt lager innebär att när en begäran rör sig från lager till lager måste den gå genom lagret precis under det för att komma till nästa lager under det lagret. Till exempel måste en begäran från presentationslagret först gå genom affärslagret och sedan till persistenslagret innan den slutligen når databaslagret.
Figur 1-2. Slutna lager och tillgång till förfrågningar
Så varför inte låta presentationslagret få direkt tillgång till antingen persistenslagret eller databaslagret? Direkt databasåtkomst från presentationslagret är trots allt mycket snabbare än att gå igenom en massa onödiga lager bara för att hämta eller spara databasinformation. Svaret på denna fråga ligger i ett nyckelkoncept som kallas isoleringslager.
Begreppet isoleringslager innebär att ändringar som görs i ett lager av arkitekturen i allmänhet inte påverkar komponenter i andra lager: ändringen är isolerad till komponenterna i det lagret och eventuellt ett annat associerat lager (t.ex. ett persistenslager som innehåller SQL). Om du ger presentationsskiktet direkt tillgång till persistensskiktet skulle ändringar av SQL i persistensskiktet påverka både affärslagret och presentationsskiktet, vilket skulle leda till ett mycket tätt kopplat program med många ömsesidiga beroenden mellan komponenterna. Denna typ av arkitektur blir då mycket svår och dyr att ändra.
Begreppet isoleringslager innebär också att varje lager är oberoende av de andra lagren och därmed har liten eller ingen kunskap om det inre arbetet i andra lager i arkitekturen. För att förstå kraften och betydelsen av detta koncept kan man tänka på ett stort refaktoriseringsarbete för att konvertera presentationsramen från JSP (Java Server Pages) till JSF (Java Server Faces). Om man antar att de kontrakt (t.ex. modell) som används mellan presentationslagret och affärslagret förblir desamma, påverkas inte affärslagret av refaktoriseringen och förblir helt oberoende av vilken typ av ram för användargränssnitt som används av presentationslagret.
Som slutna lager underlättar isolering av lager och därför hjälper till att isolera förändringar inom arkitekturen, finns det tillfällen då det är klokt att vissa lager är öppna. Anta till exempel att du vill lägga till ett lager med delade tjänster i en arkitektur som innehåller gemensamma tjänstekomponenter som komponenter inom affärslagret har tillgång till (t.ex. data- och strängverktygsklasser eller revisions- och loggningsklasser). Att skapa ett tjänsteskikt är vanligtvis en bra idé i det här fallet eftersom det arkitektoniskt begränsar åtkomsten till de delade tjänsterna till affärslagret (och inte till presentationslagret). Utan ett separat lager finns det inget arkitektoniskt som begränsar presentationslagret från att få tillgång till dessa gemensamma tjänster, vilket gör det svårt att styra denna åtkomstbegränsning.
I det här exemplet skulle det nya tjänsteskiktet sannolikt ligga under affärslagret för att ange att komponenter i detta tjänsteskikt inte är åtkomliga från presentationsskiktet. Detta innebär dock ett problem eftersom affärslagret nu måste gå genom tjänsteskiktet för att komma till persistensskiktet, vilket inte alls är meningsfullt. Detta är ett gammalt problem med en skiktad arkitektur och löses genom att skapa öppna skikt inom arkitekturen.
Som illustreras i figur 1-3 är tjänsteskiktet i det här fallet markerat som öppet, vilket innebär att förfrågningar tillåts gå förbi detta öppna skikt och gå direkt till skiktet under det. I följande exempel, eftersom tjänsteskiktet är öppet, tillåts nu affärslagret att gå förbi det och gå direkt till persistensskiktet, vilket är helt logiskt.
Figur 1-3. Öppna lager och förfrågningsflöde
Att använda begreppet öppna och slutna lager hjälper till att definiera förhållandet mellan arkitekturlager och förfrågningsflöden och ger även konstruktörer och utvecklare den information som behövs för att förstå de olika lagers åtkomstbegränsningar inom arkitekturen. Om man inte dokumenterar eller kommunicerar på rätt sätt vilka lager i arkitekturen som är öppna och stängda (och varför) resulterar det vanligtvis i tätt kopplade och sköra arkitekturer som är mycket svåra att testa, underhålla och distribuera.