4
Er is al veel geschreven over n-tier architecturen. Zo zijn er verschillende visies over hoe een n-tier architectuur eruit moet komen te zien. De verschillen in visies zijn niet zozeer zichtbaar in het conceptuele model, maar pas als er meer details in beeld komen. Voor mij is het een lange tijd onduidelijk geweest hoe ik nu concreet een n-tier architectuur kon gaan implementeren. Theoretisch wist ik precies hoe het moest. Er ontbraken telkens puzzelstukjes. Die ontbrekende puzzelstukjes heb ik kunnen vinden door me meer te gaan richten op design patterns. Ik kwam er achter dat de meeste ‘problemen’ al beschreven zijn in design patterns.
In de loop van de tijd wil ik van ontwerp tot implementatie het onderwerp N-tier architecturen uitdiepen aan de hand van een voorbeeldapplicatie.
Verder sta ik open voor (opbouwende) kritiek. Software Architectuur is iets waarover je verschillende inzichten kunt hebben. Mijn doel is om duidelijk te maken hoe ik tegen software architectuur aankijk. Als iemand er anders tegen aankijkt, aarzel dan niet om te reageren, ik hoor graag andere visies, verbeterpunten, etc. Ik kan er tenslotte ook van leren!
Als ik nadenk over mijn visie op N-Tier architecturen, realiseer ik me dat ik wel een ‘high level’ visie kan ventileren, maar dan heeft de lezer er nog niets aan. Ik wil het graag concreet houden en zal dan in de komende delen concreet en met veel voorbeelden werken. Om toch niet het overzicht te verliezen zal ik kort en krachtig uiteenzetten wat ik onder een N-Tier architectuur versta.
Wat is nu een architectuur?
De Van Dale zegt het volgende:
ar·chi·tec·tuur (de ~ (v.), -turen) 1 bouwkunst 2 bouwstijl 3 conceptuele structuur en het functionele gedrag van computer en systeemprogramma’’s of de beschrijving daarvan
De Van Dale geeft in het antwoord al aan dat het iets te maken heeft met computer- en systeemprogramma’s. Het is een beschrijving van hoe het programma er uitziet, maar dat niet alleen, want het legt ook de structuur en het functioneel gedrag vast van het programma.
Kortweg gezegd is een N-tier architectuur dus een beschrijving van een applicatie die bestaat uit een aantal (N) lagen (Tier).
Om het concreet te houden ga ik er vanuit dat het te bouwen systeem een orderverwerkend systeem is. Ik ben er namelijk van overtuigd dat ieder type systeem een andere architectuur vereist (wel of geen N-Tier). Onder type systeem versta ik bijvoorbeeld: administratieve systemen, real time systemen, games, etc.
Een N-Tier architectuur bestaat uit minimaal drie-lagen:
- Presentation Later
- Service Layer (Optioneel)
- Business Layer
- Data Access Layer
De onderste laag van een N-Tier architectuur is de Data Access Layer. Deze tier zorgt ervoor dat de data op een abstracte manier ingekapseld wordt. De Business Layer mag namelijk niet weten waar de data vandaan komt. Het kan namelijk komen uit een database (SQL-Server, Oracle , MS Access, etc) maar ook uit tekstbestanden (CSV, XML, etc). De data zou zelfs nog weer uit een ander systeem kunnen komen, bijvoorbeeld via een xml-webservice.
Kort gezegd: de Data Access Layer heeft een vaste interface. Voor de Business Layer is de Data Access Layer een black-box.
De Data Access Layer is verantwoordelijk voor het ophalen, toevoegen, wijzigen en verwijderen van data. Deze verantwoordelijkheden worden ook wel CRUD genoemd. (Create, Read, Update, Delete). Daarnaast kun je de Data Access Layer zien als een Mapper. Het mapped de data van de ene structuur naar de andere structuur, bijvoorbeeld van relationeel (database) naar objectgeoriënteerd.
Verder moet de Data Access Layer zo zijn gebouwd dat de Data Access Layer veranderd kan worden zonder dat de Business Layer er iets van merkt. Bijvoorbeeld: je hebt een Data Access Layer die connectie maakt met een Oracle database. Maar je manager heeft besloten om er xml-bestanden van te maken. Het moet dan mogelijk zijn om m.b.v. een configuratie-instelling de wijziging door te laten voeren.
De Business Layer is het hart van de applicatie. Misschien beter gezegd de hersenen. In de Business Layer wordt vastgelegd wat de applicatie doet, welke regels er zijn, welke objecten er zijn. Kortom: het gedrag van de applicatie zit hier. Het voordeel van een aparte tier voor de Business Layer is dat alle functionaliteit hergebruikt kan worden. Het heeft namelijk een duidelijke interface naar boven toe (hogere layers).
Later zal de Presentation Layer moeten communiceren met de Business Layer. Wat voor type Presentation Layer het wordt, maakt dan in principe niet meer uit. Het kan een website zijn, een windowsapplicatie, maar ook een webservice of iets dergelijks.
Boven op de Business Layer komt de Presentation Layer. Zoals de naam al doet vermoeden is dit het gezicht van de applicatie. In deze layer vind de interactie met de gebruiker plaats. De Presentation Layer heeft totaal geen idee van de Data Access Layer. Het heeft alleen interactie met de Business Layer.
In praktijk zal de Presentation Layer een website of een windowsapplicatie of een webservice met een cliënt zijn. Het type Presentation layer is afhankelijk van de eisen die gesteld worden aan de applicatie. Moet het schaalbaar zijn, moet de opslag centraal geregeld worden of per computer, moet het onderhoudsvriendelijk zijn, moet het een rich user interface hebben of niet, etc. Ook ik het mogelijk om combinaties te maken. Zo kan bijvoorbeeld een bepaalde module die alleen maar gegevens presenteert heel goed via een website worden getoond. Voor een module waar veel gegevens ingevoerd wordt, is het weer wat handiger om een windowsapplicatie te hebben, omdat die gebruikersvriendelijker is.
In een volgende post gaan we bovenstaande uitwerken in een praktisch voorbeeld.
:
Naar boven
