Wat is een n-laag-architectuur?

• 7 minuten

Met een n-laag-architectuur verdeelt u een toepassing in logische lagen en fysieke lagen. De n geeft het aantal fysieke lagen aan waarin de toepassing is verdeeld, hetgeen normaal gesproken overeenkomt met het aantal lagen. We kunnen een architectuur hebben met twee lagen (client-server) of zelfs een architectuur met vijf lagen, hoewel het gebruikelijk en vaak het beste is om het aantal lagen op vier of minder te houden.

Laten we eens kijken waaruit de lagen en niveaus bestaan.

Wat zijn lagen?

Lagen scheiden op logisch wijze de toepassingscode waaruit een toepassing bestaat. Elke laag heeft een specifieke verantwoordelijkheid, zoals het verwerken van aanvragen van gebruikers, het uitvoeren van bedrijfslogica of het verwerken van de opslag van gegevens.

Door een toepassing te scheiden in deze logische lagen behandelen we elke laag afzonderlijk. Hierdoor worden de onderdelen van de toepassing modulair en kunnen we de app gemakkelijker onderhouden. We kunnen de toepassing optimaliseren voor elke verantwoordelijkheid. De laag voor het verwerken van webaanvragen is gericht op de primaire taak: het verwerken van webaanvragen. Deze laag hoeft zich niet bezig te houden met het opslaan van gegevens of het uitvoeren van bedrijfslogica. Daarentegen is de gegevenstoegangslaag gericht op het optimaliseren van de communicatie met het gegevensarchief en negeert deze laag meer informatie over hoe de gegevens aan de gebruiker wordt gepresenteerd. Dit concept van beperken concentreert zich op specifieke functies en wordt scheiding van taken genoemd.

Hier volgt een diagram met lagen in een algemene n-laag-architectuur. Elke laag zorgt voor één aspect van de toepassing. De bedrijfslaag beheert de communicatie tussen de laag van de gebruikersinterface en de gegevenstoegangslaag.

Wat zijn niveaus?

Niveaus vertegenwoordigen de fysieke scheiding van delen van uw toepassing op afzonderlijke rekenresources. In het algemeen voert elke fysiek laag een logische laag van de toepassing uit.

Het scheiden van de architectuur in fysieke lagen heeft verschillende voordelen:

• De toepassingsonderdelen kunnen afzonderlijk worden geschaald door het toevoegen van resources aan elke laag.
• De toepassing kan robuuster zijn door taakverdeling toe te voegen om mislukte resources te detecteren en aanvragen om te leiden naar gezonde systemen.
• De toepassing kan veiliger zijn door netwerkcommunicatie tussen lagen te beperken en alleen de vereiste toegang toe te staan.

Communicatie tussen lagen moet van bovenaf plaatsvinden. Elke laag mag met de volgende laag daaronder praten, maar over het algemeen is het niet toegestaan om lagen over te slaan. Dit wordt gedaan om de veiligheid te verbeteren door de beschikbaar gemaakte surface area van een laag te beperken.

De architectuur met drie lagen

Van alle n-laag-architecturen is een architectuur met drie lagen de meest gebruikelijke. De verantwoordelijkheden en namen van elk niveau en elke laag variëren per toepassing en bedrijf, maar een typische toepassing met drie lagen heeft een presentatielaag, een toepassings- of middenlaag en een gegevenslaag. Dit de meest voorkomende stijl met een n-aantal lagen. Voor de rest van deze module verwijzen we naar een drielaags model waarbij op elke laag een enkel niveau van de toepassing wordt uitgevoerd. We noemen deze dan ook lagen.

Presentatielaag

De presentatielaag faciliteert doorgaans aanvragen van gebruikers. Dit kunnen gebruikers zijn die toegang hebben tot een webpagina of openbare toegang tot uw toepassing via een beschikbaar gemaakt API. De focus in deze laag ligt op de gebruikerservaring, het bieden van zaken zoals een intuïtieve interface en het garanderen van veilige communicatie tussen de eindgebruiker en uw toepassing.

Bij deze laag bent u niet betrokken bij de gegevens zelf, met andere woorden, hoe deze aan de gebruiker worden gepresenteerd. Normaal gesproken gebeurt er geen gegevensverwerking of gegevenstoegang op deze laag. Dit is de verantwoordelijkheid van de lagere lagen.

Toepassingslaag

De toepassingslaag (ook vaak de middelste laag genoemd) is typisch gericht op het verwerken van de bedrijfslogica van de toepassing. Dit kan het verwerken van een klantorder zijn, een verzending volgen of voorraad bijwerken op basis van ontvangen materialen. Deze laag is ook verantwoordelijk voor het maken, lezen, bijwerken en verwijderen van activiteiten (CRUD) op basis van de gegevenslaag. Dit is ook een goede locatie voor aanroepen naar afhankelijke services, zoals externe API's.

Deze laag maakt zich geen zorgen over de manier waarop de informatie aan de gebruiker wordt gepresenteerd, noch over de manier waarop de gegevens worden opgeslagen en opgehaald. De focus ligt op de benodigde bedrijfslogica om te voldoen aan de aanvraag die de toepassing heeft ontvangen.

Gegevenslaag

In deze laag ligt de focus op gegevensopslag. Opslag van de gegevens in tabellen, bestanden of andere media is de verantwoordelijkheid van deze laag. Deze laag biedt een interface (zoals T-SQL) voor toegang tot de gegevens. In een architectuur met drie lagen biedt de gegevenslaag toegang tot gegevens in de toepassingslaag.

Deze laag is niet gericht op hoe de gegevens aan de gebruiker worden gepresenteerd en is ook niet gericht op enige logica rondom de gegevens. Het gebruik van opgeslagen procedures kan in deze laag zitten, maar de meeste logica rond de gegevens zelf moet op een hoger niveau worden behandeld.

Wanneer worden n-laag-architecturen gebruikt

Nu we hebben besproken wat een n-laag-architectuur is, gaan we beschrijven wanneer u een architectuur van deze stijl zou gebruiken. Overweeg een n-laag-architectuur voor:

• Kleine tot middelgrote webtoepassingen
• Het migreren van een on-premises toepassing naar Azure met minimale herstructurering
• Gebruikmaken van vaardigheden en mogelijkheden voor ontwikkelaars met on-premises ervaring

Webtoepassingen zijn een goede use-case voor architecturen van deze stijl. Vanwege de verminderde complexiteit van deze architecturen en de vaak natuurlijke scheiding tussen verantwoordelijkheden in webtoepassingen, kunnen n-laag-architecturen goed werken. Dit kunnen openbare toepassingen zijn of line-of-business-toepassingen die intern worden gebruikt door een organisatie. Voor kleinere of minder complexe toepassingen is een architectuur met twee lagen (client/server) mogelijk voldoende, met de presentatie- en toepassingslagen gecombineerd in plaats van gescheiden.

N-laag-architecturen zijn gebruikelijk in traditionele on-premises toepassingen. Deze liggen dus voor de hand om bestaande workloads naar Azure te migreren. Toepassingen in deze stijl worden vaak gemigreerd naar Azure met minimale herstructurering of aanpassingen, waardoor de eerste migratie eenvoudiger wordt. Eenmaal in Azure kunt u profiteren van platform as a service (PaaS)-services om uw toepassing verder te verbeteren.

Omdat dit een algemene architectuurstijl is, hebben technici vaak een hoger niveau van ervaring en zijn ze er bekend mee. Door deze architectuur te kiezen, kunt u bestaande vaardighedensets gebruiken om toepassingen te implementeren zonder dat u nieuwe architectuurpatronen nodig hebt.

Test uw kennis