Lagerarkitektur organiserar källkod i lager, där varje lager ansvarar för en viss sorts arbete. Den skiljer mottagning av begäranden, tillämpning av verksamhetsregler och dataåtkomst, så att koden blir lättare att förstå och underhålla.
Lagren kan köras i en enda applikation. Lager beskriver kodens ansvar; att placera delar på separata servrar är en driftsättningsfråga som hanteras av N-tier-arkitektur.
En webbapplikation har ofta tre lager:
Vid traditionell lagerindelning anropar presentationen verksamhetslogiken, som anropar dataåtkomsten. Det håller databasfrågor och verksamhetsregler utanför presentationskoden.
Tänk på en applikation för ledighetshantering: När en anställd skickar in en ansökan tar presentationen emot datumen och lämnar dem till verksamhetslogiken. Verksamhetslogiken hämtar den återstående ledigheten genom dataåtkomsten och kontrollerar ansökan.
Om den är giltig sparar applikationen ansökan för godkännande och returnerar en bekräftelse. Om ledigheten inte räcker avvisar verksamhetslogiken ansökan, och presentationen visar orsaken. I det här exemplet dras ledigheten av senare, vid godkännandet.
När företaget ändrar sin ledighetspolicy uppdaterar utvecklarna verksamhetslagret. Presentation och datalagring kan förbli oförändrade om den information som utbyts är densamma.
Lagerarkitektur passar administrationsverktyg, HR-applikationer och system med många formulär och välbekanta verksamhetsflöden. För ett större system bör koden delas in i verksamhetsmoduler med lager inom varje modul, så att man undviker ett enormt verksamhetslager som innehåller alla funktioner.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera