Wat is een n-laag-architectuur?
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. Deze scheiding maakt de onderdelen van de toepassing modulair en stelt ons in staat om de app gemakkelijker te 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. Het gaat niet om de opslag van gegevens of het uitvoeren van bedrijfslogica. De gegevenstoegangslaag is daarentegen gericht op het optimaliseren van de communicatie met het gegevensarchief en negeert details over hoe gegevens aan de gebruiker worden 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 toleranter 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.
De architectuur bepaalt dat de communicatie tussen lagen op een top-down manier moet zijn. Elke laag kan met de volgende laag eronder praten, maar over het algemeen is het niet toegestaan om lagen over te slaan. Dit ontwerp verbetert de beveiliging door het blootgestelde oppervlak 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. Deze architectuur is de meest voorkomende N-laagstijl. Voor de rest van deze module verwijzen we naar een model met drie lagen met elke laag waarop één laag van de toepassing wordt uitgevoerd en verwijzen we ernaar als lagen.
Presentatielaag
De presentatielaag faciliteert doorgaans aanvragen van gebruikers. Deze aanvragen kunnen gebruikers zijn die toegang hebben tot een webpagina of openbare toegang tot uw toepassing via een beschikbaar gemaakte API. De focus op deze laag ligt op de gebruikerservaring. Het bieden van zaken als een intuïtieve interface en het garanderen van veilige communicatie tussen de eindgebruiker en uw toepassing.
In deze laag maakt u zich geen zorgen over de gegevens zelf, behalve de wijze waarop deze aan de gebruiker worden gepresenteerd. Normaal gesproken is er geen gegevensverwerking of gegevenstoegang die op deze laag plaatsvindt. 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 wijze waarop de informatie aan de gebruiker wordt gepresenteerd, noch maakt het zich zorgen over hoe 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 de manier waarop de gegevens aan de gebruiker worden gepresenteerd, noch is deze gericht op logica rond de gegevens. Het gebruik van opgeslagen procedures kan zich in deze laag bevinden, maar de meeste logica rond de gegevens moet worden verwerkt op een hogere laag.
Wanneer worden n-laag-architecturen gebruikt
Nu we het hebben gehad over wat een N-tier-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.
- De vaardigheden, mogelijkheden en ervaring van on-premises ontwikkelaars gebruiken.
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. Deze toepassingen kunnen openbaar zijn of line-of-business-toepassingen die intern door een organisatie worden gebruikt. 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 PaaS-services (Platform as a Service) om uw toepassing verder te verbeteren.
Omdat dit een algemene architectuurstijl is, hebben technici vaak een hoger niveau van ervaring en bekendheid met het. Als u kiest voor deze architectuur kunt u bestaande vaardighedensets gebruiken om toepassingen te implementeren zonder nieuwe architectuurpatronen.