Inhoudsopgave:
- Er zijn verschillende algemene benaderingen voor de toepassingsarchitectuur die variëren afhankelijk van het aantal gebruikte lagen. Een veelgebruikt schema is om de toepassing in twee lagen te splitsen:
- Een ander algemeen model voor het ontwerpen van webtoepassingen is
Video: (#2) What's new in .NET Core 3.0 | .NET Core 3.0 tutorial 2024
Een benadering voor het ontwerpen van webtoepassingen is om zich te concentreren op duidelijk gedefinieerde lagen van de architectuur van de applicatie. Deze aanpak is vergelijkbaar met de manier waarop een architect een gebouw ontwerpt. Als je ooit gedetailleerde bouwplannen voor een wolkenkrabber hebt gezien, weet je dat de bouwplannen afzonderlijke blauwdrukken bevatten voor de fundering, het frame, het dak, het loodgieterswerk, de elektriciteit en andere verdiepingen van het gebouw.
Met een gelaagde architectuur kunnen specialisten de "vloeren" - de zogenaamde lagen - onafhankelijk ontwerpen en ontwikkelen, op voorwaarde dat de verbindingen tussen de lagen (de interfaces >) zijn zorgvuldig doordacht. De lagen moeten zo veel mogelijk onafhankelijk van elkaar zijn. Dat betekent onder andere dat je moet letten op enkele must-do's en shalt-nots:
Elke laag moet een duidelijk gedefinieerde focus hebben.
- Om de lagen goed te ontwerpen, moet u de taken en verantwoordelijkheden van elke laag duidelijk omschrijven.
- Als één laag verantwoordelijk is voor gebruikersinteractie, mag alleen die laag met de gebruiker communiceren. Andere lagen die informatie van de gebruiker moeten ophalen, moeten dit doen via de gebruikersinterfacelaag. Er moeten duidelijk gedefinieerde protocollen worden ingesteld zodat de lagen met elkaar kunnen communiceren.
- Interactie tussen de lagen vindt alleen plaats via deze protocollen.
Hoeveel lagen?
Er zijn verschillende algemene benaderingen voor de toepassingsarchitectuur die variëren afhankelijk van het aantal gebruikte lagen. Een veelgebruikt schema is om de toepassing in twee lagen te splitsen:
Toepassingslaag:
- Het ontwerp van de gebruikersinterface en de implementatie van bedrijfsbeleid worden in deze laag verwerkt. Deze laag kan ook omgaan met transactielogica - de code die database-updates groepeert in transacties en zorgt ervoor dat alle updates binnen een transactie consistent worden gemaakt. Datatoegangslaag:
- De onderliggende database-engine die de toepassing ondersteunt. Deze laag is verantwoordelijk voor het handhaven van de integriteit van de database. Sommige of alle transactielogica kan in deze laag worden geïmplementeerd. In het tweelagenmodel is de toepassingslaag de ASP. NET-webpagina's die de pagina's definiëren die aan de gebruiker worden gepresenteerd, evenals de code achter de bestanden die de logica van de toepassing implementeren. De gegevenstoegangslaag is de databaseserver die de database beheert, zoals Microsoft SQL Server of Oracle.
Merk op dat ASP. NET 2. 0 vereist niet dat u de logica-code van de toepassing in een apart code-achter-bestand plaatst. In plaats daarvan kunt u de logica-code met de presentatiecode in hetzelfde bestand doorspitten. Het is echter bijna altijd een goed idee om afzonderlijke code achter de bestanden te gebruiken om de logica van de toepassing te scheiden van de presentatiecode. Alle toepassingen die in dit boek worden gepresenteerd, maken gebruik van afzonderlijke code-achter-bestanden.
De scheiding tussen de lagen Toepassing en Gegevenstoegang is niet altijd zo duidelijk als mogelijk. Om prestatieredenen wordt transactielogica vaak verschoven naar de databaseserver (in de vorm van opgeslagen procedures) en bedrijfsregels worden vaak geïmplementeerd op de databaseserver met beperkingen en triggers. De databaseserver verwerkt dus vaak een deel van de toepassingslogica.
Als u deze rommel ondervindt, kunt u een
architectuur met drie lagen gebruiken, die een extra laag toevoegt voor het verwerken van bedrijfsregels en beleid: Presentatielaag:
- Deze laag verwerkt de gebruiker interface. Business Rules Layer:
- Deze laag verwerkt de bedrijfsregels en het beleid van de toepassing. Als een verkoopapplicatie bijvoorbeeld kortingen toekent aan bepaalde gebruikers, wordt het kortingsbeleid geïmplementeerd in deze laag. Datatoegangslaag:
- Het onderliggende databasemodel dat de toepassing ondersteunt. Als u een afzonderlijke laag voor bedrijfsregels maakt, kunt u de regels scheiden van het databaseontwerp en de presentatielogica. Bedrijfsregels kunnen worden gewijzigd. Door ze in een afzonderlijke laag te plaatsen, kunt u ze later gemakkelijker wijzigen dan wanneer ze zijn opgenomen in de gebruikersinterface of het databaseontwerp.
Model-View-Controller
Een ander algemeen model voor het ontwerpen van webtoepassingen is
Model-View-Controller ( MVC ). In deze architectuur bestaat de toepassing uit drie delen: Model
- : het -model is in feite de bedrijfslaag van de toepassing. Het bestaat meestal uit objecten die de bedrijfsentiteiten vertegenwoordigen die deel uitmaken van de toepassing, zoals klanten en producten. Weergave:
- De weergave is de gebruikersinterface van de toepassing. In een webtoepassing bestaat dit uit een of meer HTML-pagina's die het uiterlijk van de toepassing bepalen. Controller:
- De -controller beheert de gebeurtenissen die door de toepassing worden verwerkt. De gebeurtenissen worden meestal gegenereerd door acties van de gebruikersinterface, zoals de gebruiker die op een knop klikt of een item in een vervolgkeuzelijst selecteert. In een typische ASP. NETTO-applicatie, de. aspx-bestand implementeert de weergave; de model- en controller-functies worden gecombineerd en afgehandeld door het code-behind-bestand. Het code achterliggende bestand kan dus worden beschouwd als de
model-controller . U kunt de model- en controllerfuncties natuurlijk scheiden door aparte klassen voor de bedrijfsentiteiten te maken. Voor de eenvoud houden de toepassingen in dit boek de model- en controller-functies in het code-behind-bestand samen.
