Inleiding tot de MVC-architectuur
De meest populaire applicatiearchitectuur die elke programmeur kent, is MVC . MVC staat voor Model-View-Controller .
Dit is niet zozeer de architectuur van applicaties als wel de architectuur van applicatiecomponenten, maar we komen later op deze nuance terug. Wat is MVC?
MVC is een schema voor het scheiden van applicatiegegevens en besturingslogica in drie afzonderlijke componenten: model, weergave en controller , zodat elk onderdeel onafhankelijk kan worden gewijzigd.
- Model (Model) levert gegevens en reageert op controlleropdrachten door de status te wijzigen.
- De weergave is verantwoordelijk voor het weergeven van modelgegevens aan de gebruiker als reactie op modelwijzigingen.
- De Controller (Controller) interpreteert de acties van de gebruiker en stelt het model op de hoogte van de noodzaak van wijzigingen.
Dit model is uitgevonden in 1978 (!) Jaar. Ja, problemen met de juiste software-architectuur waren 50 jaar geleden relevant. Hier is hoe dit model wordt beschreven door het diagram in het origineel:
Het model biedt gegevens en methoden om ermee te werken: query's naar de database, controle op juistheid. Het model is onafhankelijk van de weergave (weet niet hoe gegevens moeten worden weergegeven) en de controller (heeft geen gebruikersinteractiepunten) en biedt toegang tot en beheer van gegevens.
Het model is zo gebouwd dat het reageert op verzoeken door de status te wijzigen, en de melding van "waarnemers" kan worden ingebouwd. Het model kan, vanwege de onafhankelijkheid van de visuele weergave, meerdere verschillende weergaven hebben voor één "model".
De weergave is verantwoordelijk voor het ophalen van de vereiste gegevens uit het model en het verzenden ervan naar de gebruiker. De weergave verwerkt geen gebruikersinvoer.
De controller zorgt voor de "communicatie" tussen de gebruiker en het systeem. Regelt en leidt gegevens van de gebruiker naar het systeem en vice versa. Gebruikt een model en een weergave om de gewenste actie te implementeren.
Er is een zekere moeilijkheid met het feit dat dit model in de loop van de decennia een beetje is geëvolueerd. Dat wil zeggen, de naam bleef hetzelfde, maar het doel van de onderdelen begon te veranderen.
MVC-architectuur op het web
Het idee achter het MVC-ontwerppatroon is heel eenvoudig: we moeten de verantwoordelijkheid voor verschillende gedragingen in onze toepassingen duidelijk scheiden:
Model— gegevensverwerking en toepassingslogica.
weergave— het verstrekken van gegevens aan de gebruiker in elk ondersteund formaat.
Controleur- het verwerken van gebruikersverzoeken en het aanroepen van de juiste bronnen.
De applicatie is verdeeld in drie hoofdcomponenten, die elk verantwoordelijk zijn voor verschillende taken. Laten we de componenten van een client-servertoepassing nader bekijken aan de hand van een voorbeeld.
Controleur
De gebruiker klikt op verschillende elementen op de pagina in de browser, waardoor de browser verschillende HTTP-verzoeken verzendt: GET, POST of andere. De controller kan de browser en JS-code bevatten die binnen de pagina werken.
De belangrijkste functie van de controller in dit geval is om methoden op de benodigde objecten aan te roepen, de toegang tot bronnen te beheren om taken uit te voeren die door de gebruiker zijn gespecificeerd. Gewoonlijk roept de controller het juiste model voor de taak aan en selecteert de juiste weergave.
Model
Model in brede zin zijn de gegevens en regels die worden gebruikt om met de gegevens te werken - samen vormen ze de bedrijfslogica van de toepassing. Het ontwerpen van een applicatie begint altijd met het bouwen van modellen van de objecten waarop het werkt.
Laten we zeggen dat we een online winkel hebben die boeken verkoopt, is een persoon dan alleen een applicatiegebruiker of ook een auteur van een boek? Deze belangrijke vragen moeten worden beantwoord tijdens het modelontwerp.
Verder zijn er sets van regels: wat kan wel, wat kan niet, welke datasets zijn acceptabel en welke niet. Kan een boek bestaan zonder auteur? En de auteur zonder boeken? Kan de geboortedatum van de gebruiker in het jaar 300 vallen, enzovoort.
Het model geeft de controller zicht op de gegevens die de gebruiker heeft opgevraagd (bericht, boekpagina, foto's, enz.). Het datamodel blijft hetzelfde, ongeacht hoe we het aan de gebruiker willen presenteren. Daarom kiezen we elke beschikbare weergave om de gegevens weer te geven.
Het model bevat het belangrijkste deel van onze applicatielogica , de logica die het probleem oplost waarmee we te maken hebben (forum, winkel, bank, enz.). De controller bevat vooral organisatorische logica voor de applicatie zelf (net als je Project Manager).
Weergave
View biedt verschillende manieren om de gegevens weer te geven die van het model worden ontvangen. Het kan een sjabloon zijn die is gevuld met gegevens. Er kunnen verschillende weergaven zijn en de controller kiest welke het beste is voor de huidige situatie.
Een webapplicatie bestaat meestal uit een set controllers, modellen en views. De controller kan alleen op de backend staan, maar er kan ook een variant zijn van meerdere controllers, wanneer de logica ook over de frontend wordt verspreid. Een goed voorbeeld van deze aanpak is elke mobiele applicatie.
MVC-voorbeeld op internet
Stel dat u een online winkel moet ontwikkelen die boeken gaat verkopen. De gebruiker kan de volgende acties uitvoeren: boeken bekijken, registreren, kopen, items toevoegen aan de huidige bestelling, boeken markeren die hij leuk vindt en ze kopen.
Uw toepassing moet een model hebben dat verantwoordelijk is voor alle bedrijfslogica. U hebt ook een controller nodig die alle gebruikersacties verwerkt en deze omzet in methodeaanroepen vanuit bedrijfslogica. Eén controllermethode kan echter veel verschillende modelmethoden aanroepen.
Je hebt ook weergavesets nodig: een lijst met boeken, informatie over één boek, een winkelwagentje, een lijst met bestellingen. Elke pagina van een webapplicatie is eigenlijk een aparte weergave die een bepaald aspect van het model aan de gebruiker toont.
Laten we eens kijken wat er gebeurt als een gebruiker een lijst met door de boekhandel aanbevolen boeken opent om titels te bekijken. De hele reeks acties kan worden beschreven in de vorm van 6 stappen:
Stappen:
- De gebruiker klikt op de "aanbevolen" link en de browser stuurt een verzoek naar bijvoorbeeld /books/recommendations.
- De controller controleert het verzoek : de gebruiker moet ingelogd zijn. Of we zouden collecties boeken moeten hebben voor niet-ingelogde gebruikers. De controller roept vervolgens het model op en vraagt het om de lijst met aanbevolen boeken aan gebruiker N terug te sturen.
- Het model benadert de database, haalt daar informatie over boeken uit: boeken die momenteel populair zijn, boeken gekocht door de gebruiker, boeken gekocht door zijn vrienden, boeken van zijn verlanglijst. Op basis van deze gegevens stelt het model een lijst samen van 10 aanbevolen boeken en stuurt deze terug naar de controller.
- De controller ontvangt een lijst met aanbevolen boeken en bekijkt deze. In dit stadium neemt de controller beslissingen! Als er weinig boeken zijn of de lijst helemaal leeg is, vraagt het een lijst met boeken op voor een niet-ingelogde gebruiker. Als er op dit moment een actie loopt, kan de controller actieboeken aan de lijst toevoegen.
- De controller bepaalt welke pagina aan de gebruiker wordt getoond. Het kan een foutpagina zijn, een pagina met een boekenlijst, een pagina die feliciteert dat de gebruiker een miljoenste bezoeker is geworden.
- De server geeft de client de door de controller geselecteerde pagina ( view ). Het wordt gevuld met de nodige gegevens (gebruikersnaam, boekenlijst) en gaat naar de klant.
- De client ontvangt de pagina en geeft deze weer aan de gebruiker.
Wat zijn de voordelen van deze aanpak?
Het meest voor de hand liggende voordeel dat we halen uit het gebruik van het MVC-concept is een duidelijke scheiding van presentatielogica (gebruikersinterface) en applicatielogica (backend).
Het tweede voordeel is de opdeling van het serverdeel in tweeën: een slim model ( uitvoerder ) en een controller ( beslissingscentrum ).
In het vorige voorbeeld was er een moment waarop de controller een lege lijst met aanbevolen boeken van het model kon ontvangen en kon beslissen wat hij ermee deed. Theoretisch zou deze logica direct in het model kunnen worden gezet.
Ten eerste zou het model bij het aanvragen van aanbevolen boeken beslissen wat te doen als de lijst leeg is. Dan zou ik de code op dezelfde plek moeten toevoegen, wat te doen als er nu een actie gaande is, dan meer verschillende opties.
Toen bleek dat de winkelbeheerder wilde zien hoe de pagina van de gebruiker eruit zou zien zonder promotie, of vice versa, er is nu geen promotie, maar hij wil zien hoe de toekomstige promotie wordt weergegeven. En daar zijn geen methoden voor. Daarom is ervoor gekozen om het beslissingscentrum (controller) los te koppelen van de bedrijfslogica (model).
Naast het isoleren van weergaven van applicatielogica, vermindert het MVC-concept de complexiteit van grote applicaties aanzienlijk. De code is veel meer gestructureerd, waardoor het eenvoudiger wordt om oplossingen te onderhouden, testen en hergebruiken.
Als u het concept van MVC begrijpt, beseft u als ontwikkelaar waar u de lijst met boeken moet sorteren:
- Op databasequeryniveau.
- Op het niveau van bedrijfslogica (model).
- Op het niveau van de bedrijfslogica (controller).
- In het zicht - aan de kant van de klant.
En dit is geen retorische vraag. Bedenk nu waar en waarom u de code moet toevoegen om de lijst met boeken te sorteren.
Klassiek MVC-model
Interactie tussen MVC-componenten wordt anders geïmplementeerd in webapplicaties en mobiele applicaties. Dit komt omdat de web-app van korte duur is, één gebruikersverzoek verwerkt en afsluit, terwijl de mobiele app veel verzoeken verwerkt zonder opnieuw op te starten.
Webapplicaties gebruiken doorgaans het "passieve" model, terwijl mobiele applicaties het "actieve" model gebruiken. Met het actieve model kunt u zich, in tegenstelling tot het passieve, abonneren en meldingen ontvangen over wijzigingen daarin. Voor webapplicaties is dit niet vereist.
Zo ziet de interactie van componenten in verschillende modellen eruit:
Mobiele applicaties (actief model) maken actief gebruik van gebeurtenissen en het mechanisme voor het inschrijven op gebeurtenissen. Met deze aanpak onderschrijft view ( view ) modelwijzigingen. Wanneer er vervolgens een gebeurtenis plaatsvindt (de gebruiker klikt bijvoorbeeld op een knop), wordt de controller aangeroepen . Het geeft het model ook een opdracht om de gegevens te wijzigen.
Als sommige gegevens zijn gewijzigd, genereert het model een gebeurtenis over het wijzigen van deze gegevens. Alle weergaven die zich hebben aangemeld voor deze gebeurtenis (waarvoor het belangrijk is om deze specifieke gegevens te wijzigen) ontvangen deze gebeurtenis en werken de gegevens bij in hun interface.
In webapplicaties zijn de zaken iets anders georganiseerd. Het belangrijkste technische verschil is dat de client geen server-side berichten kan ontvangen op initiatief van de server .
Daarom stuurt een controller in een webapplicatie meestal geen berichten naar de view, maar geeft de client een nieuwe pagina, wat technisch gezien een nieuwe view is of zelfs een nieuwe clientapplicatie (als de ene pagina niets weet over de andere). .
Op dit moment wordt dit probleem gedeeltelijk opgelost met behulp van de volgende benaderingen:
- De server regelmatig peilen naar wijzigingen in belangrijke gegevens (een keer per minuut of vaker).
- Met websockets kan een client zich abonneren op serverberichten.
- Webpushmeldingen vanaf de serverzijde.
- Met het HTTP/2-protocol kan de server het verzenden van berichten naar de client starten.
GO TO FULL VERSION