In dit artikel leren we iets kennen dat MVC heet. We zullen het hebben over wat MVC is, de geschiedenis ervan bespreken, de basisideeën en -concepten verkennen die in MVC zijn belichaamd, stap voor stap bekijken hoe een applicatie kan worden opgedeeld in Model-, View- en Controller-modules, een kleine webapplicatie met behulp van Spring Boot en, met Spring MVC als voorbeeld, hoe gegevens van Java-code naar HTML-pagina's worden verzonden. Om dit materiaal te begrijpen, moet u bekend zijn met ontwerppatronen, met name waarnemer en gevel. En wees bekend met HTTP-verzoeken en -antwoorden, begrijp de basisprincipes van HTML en weet wat Java-annotaties zijn. Pak een kopje koffie en een snack en maak het je gemakkelijk. Laten we beginnen.
Geschiedenis van MVC
De ideeën achter MVC zijn geformuleerd door Trygve Reenskaug toen hij eind jaren zeventig bij Xerox PARC werkte. In die tijd vereiste het werken met computers een diploma en een constante studie van omvangrijke documentatie. De taak die Reenskaug samen met een groep zeer sterke ontwikkelaars oploste, was om de interactie van een gewone gebruiker met de computer te vereenvoudigen. Het was noodzakelijk om tools te maken die enerzijds uiterst eenvoudig en begrijpelijk zouden zijn, en anderzijds het mogelijk zouden maken om computers en complexe applicaties te besturen. Reenskaug werkte aan een team dat onder leiding van Alan Kay een laptop ontwikkelde "voor kinderen van alle leeftijden" - de Dynabook, evenals de SmallTalk-taal. Dat was toen de concepten van een vriendelijke interface werden vastgelegd. In veel opzichten, het werk van Reenskaug en zijn team heeft de evolutie van de IT-sfeer beïnvloed. Hier is een interessant feit dat niet direct van toepassing is op MVC, maar het belang van deze ontwikkelingen illustreert. Alan Kaygezegd, "Toen ik voor het eerst bij Apple kwam, dat was in '84, was de Mac al uit en Newsweek nam contact met me op en vroeg me wat ik van de Mac vond. Ik zei: 'Nou, de Mac is de eerste personal computer die goed genoeg is om bekritiseerd worden.' Dus nadat hij in 2007 de iPhone had aangekondigd, bracht hij hem naar me toe en overhandigde hem aan mij. Hij zei: 'Alan, is dit goed genoeg om bekritiseerd te worden?' En ik zei: 'Steve, maak het zo groot als een tablet en je zult de wereld regeren.'" Na 3 jaar, op 27 januari 2010, introduceerde Apple de iPad met een diagonaal van 9,7 inch. Met andere woorden, Steve Jobs volgde het advies van Alan Kay bijna precies op. Het project van Reenskaug duurde 10 jaar. Maar de eerste publicatie over MVC kwam na nog eens 10 jaar aan het licht. Martin Fowler, auteur van verschillende boeken en artikelen over software-architectuur, vermeldt dat hij MVC bestudeerde met behulp van een werkende versie van Smalltalk. Omdat er lange tijd geen informatie over MVC uit de oorspronkelijke bron was, en om verschillende andere redenen, verschenen er een groot aantal verschillende interpretaties van dit concept. Als gevolg hiervan beschouwen velen MVC als een ontwerppatroon. Minder vaak wordt MVC een samengesteld patroon genoemd of een combinatie van verschillende patronen die samenwerken om complexe toepassingen te creëren. Maar zoals eerder vermeld, is MVC eigenlijk in de eerste plaats een reeks architecturale ideeën/principes/benaderingen die op verschillende manieren kunnen worden geïmplementeerd met behulp van verschillende patronen... Vervolgens zullen we de belangrijkste ideeën bekijken die zijn ingebed in het MVC-concept. en om verschillende andere redenen verschenen er een groot aantal verschillende interpretaties van dit concept. Als gevolg hiervan beschouwen velen MVC als een ontwerppatroon. Minder vaak wordt MVC een samengesteld patroon genoemd of een combinatie van verschillende patronen die samenwerken om complexe toepassingen te creëren. Maar zoals eerder vermeld, is MVC eigenlijk in de eerste plaats een reeks architecturale ideeën/principes/benaderingen die op verschillende manieren kunnen worden geïmplementeerd met behulp van verschillende patronen... Vervolgens zullen we de belangrijkste ideeën bekijken die zijn ingebed in het MVC-concept. en om verschillende andere redenen verschenen er een groot aantal verschillende interpretaties van dit concept. Als gevolg hiervan beschouwen velen MVC als een ontwerppatroon. Minder vaak wordt MVC een samengesteld patroon genoemd of een combinatie van verschillende patronen die samenwerken om complexe toepassingen te creëren. Maar zoals eerder vermeld, is MVC eigenlijk in de eerste plaats een reeks architecturale ideeën/principes/benaderingen die op verschillende manieren kunnen worden geïmplementeerd met behulp van verschillende patronen... Vervolgens zullen we de belangrijkste ideeën bekijken die zijn ingebed in het MVC-concept.
MVC: basisideeën en principes
VC is een reeks architecturale ideeën en principes voor het bouwen van complexe informatiesystemen met een gebruikersinterface
MVC is een afkorting die staat voor: Model-View-Controller
Disclaimer: MVC is geen ontwerppatroon. MVC is een reeks architecturale ideeën en principes voor het bouwen van complexe systemen met een gebruikersinterface. Maar voor het gemak, om niet herhaaldelijk "een reeks architectonische ideeën..." te zeggen, verwijzen we naar het MVC-patroon. Laten we beginnen met het simpele. Wat zit er verborgen achter de woorden Model-View-Controller? Wanneer u het MVC-patroon gebruikt om systemen met een gebruikersinterface te ontwikkelen, moet u het systeem in drie componenten verdelen. Ze kunnen ook modules of componenten worden genoemd. Noem ze wat je wilt, maar verdeel het systeem in drie componenten. Elk onderdeel heeft zijn eigen doel. Model. De eerste component/module wordt het model genoemd. Het bevat alle bedrijfslogica van de applicatie. Weergave.Het tweede deel van het systeem is het uitzicht. Deze module is verantwoordelijk voor het weergeven van gegevens aan de gebruiker. Alles wat de gebruiker ziet, wordt gegenereerd door de weergave. Controleur.De derde schakel in deze keten is de verwerkingsverantwoordelijke. Het bevat de code die verantwoordelijk is voor het afhandelen van gebruikersacties (alle gebruikersacties worden afgehandeld in de controller). Het model is het meest onafhankelijke onderdeel van het systeem. Zo onafhankelijk dat het niets mag weten van de view- en controllermodules. Het model is zo onafhankelijk dat de ontwikkelaars vrijwel niets weten over de weergave en controller. Het belangrijkste doel van de weergave is om informatie van het model te verstrekken in een indeling die de gebruiker kan gebruiken. De belangrijkste beperking van de weergave is dat deze het model op geen enkele manier mag wijzigen. Het belangrijkste doel van de controller is om gebruikersacties af te handelen. Het is via de controller dat de gebruiker wijzigingen in het model aanbrengt. Of beter gezegd, naar de data die in het model is opgeslagen. Dit is het diagram dat je eerder in de les zag: Uit dit alles kunnen we een logische conclusie trekken. Een complex systeem moet worden opgedeeld in modules. Laten we kort de stappen beschrijven om deze scheiding te bereiken.
Stap 1. Scheid de bedrijfslogica van de applicatie van de gebruikersinterface
Het hoofdidee van MVC is dat elke applicatie met een gebruikersinterface kan worden onderverdeeld in 2 modules: een module die verantwoordelijk is voor het implementeren van de bedrijfslogica en de gebruikersinterface. De eerste module implementeert de belangrijkste functionaliteit van de applicatie. Deze module vormt de kern van het systeem, waarin het domeinmodel van de applicatie wordt geïmplementeerd. In het MVC-paradigma is deze module de letter M, ofwel het model. De tweede module implementeert de volledige gebruikersinterface, inclusief de logica om gegevens aan de gebruiker weer te geven en de gebruikersinteractie met de applicatie af te handelen. Het belangrijkste doel van deze scheiding is ervoor te zorgen dat de kern van het systeem (het "model" in MVC-terminologie) onafhankelijk kan worden ontwikkeld en getest. Na het maken van deze scheiding ziet de architectuur van de applicatie er als volgt uit:
Stap 2 Gebruik het waarnemerspatroon om het model nog onafhankelijker te maken en gebruikersinterfaces te synchroniseren
Hier hebben we 2 doelen:
Bereik nog meer onafhankelijkheid voor het model
Synchroniseer gebruikersinterfaces
Het volgende voorbeeld helpt u te begrijpen wat we bedoelen met synchronisatie van gebruikersinterfaces. Stel dat we online een bioscoopkaartje kopen en het aantal beschikbare stoelen in de bioscoop zien. Tegelijkertijd kan iemand anders een bioscoopkaartje kopen. Als deze andere persoon vóór ons een kaartje koopt, zien we graag een vermindering van het aantal beschikbare stoelen voor de showtime die we overwegen. Laten we nu eens kijken hoe dit binnen een programma kan worden geïmplementeerd. Stel dat we de kern van ons systeem (ons model) en interface (de webpagina voor het kopen van kaartjes) hebben. Twee gebruikers proberen tegelijkertijd een stoel in het theater te kiezen. De eerste gebruiker koopt een kaartje. De webpagina moet aan de tweede gebruiker laten zien dat dit is gebeurd. Hoe moet dit gebeuren? Als we de interface vanuit de kern updaten, dan zal de kern (ons model) afhankelijk zijn van de interface. Bij het ontwikkelen en testen van het model zullen we rekening moeten houden met de verschillende manieren om de interface bij te werken. Om dit te bereiken, moeten we het waarnemerspatroon implementeren. Met dit patroon kan het model wijzigingsmeldingen naar alle listeners sturen. Als gebeurtenisluisteraar (of waarnemer) ontvangt de gebruikersinterface meldingen en wordt deze bijgewerkt. Enerzijds laat het waarnemerspatroon het model de interface (view en controller) informeren dat er veranderingen hebben plaatsgevonden zonder er daadwerkelijk iets van af te weten, waardoor het onafhankelijk blijft. Aan de andere kant maakt het het mogelijk om gebruikersinterfaces te synchroniseren. we moeten het waarnemerspatroon implementeren. Met dit patroon kan het model wijzigingsmeldingen naar alle listeners sturen. Als gebeurtenisluisteraar (of waarnemer) ontvangt de gebruikersinterface meldingen en wordt deze bijgewerkt. Enerzijds laat het waarnemerspatroon het model de interface (view en controller) informeren dat er veranderingen hebben plaatsgevonden zonder er daadwerkelijk iets van af te weten, waardoor het onafhankelijk blijft. Aan de andere kant maakt het het mogelijk om gebruikersinterfaces te synchroniseren. we moeten het waarnemerspatroon implementeren. Met dit patroon kan het model wijzigingsmeldingen naar alle listeners sturen. Als gebeurtenisluisteraar (of waarnemer) ontvangt de gebruikersinterface meldingen en wordt deze bijgewerkt. Enerzijds laat het waarnemerspatroon het model de interface (view en controller) informeren dat er veranderingen hebben plaatsgevonden zonder er daadwerkelijk iets van af te weten, waardoor het onafhankelijk blijft. Aan de andere kant maakt het het mogelijk om gebruikersinterfaces te synchroniseren.
Stap 3 Scheid de interface in weergave en controller
We gaan door met het opdelen van de applicatie in modules, maar nu op een lager niveau in de hiërarchie. Bij deze stap wordt de gebruikersinterface (die we in stap 1 hebben gescheiden in een aparte module) opgesplitst in een weergave en een controller. Een strikte grens trekken tussen het uitzicht en de controller is moeilijk. Als we zeggen dat de weergave is wat de gebruiker ziet, en de controller het mechanisme is waarmee de gebruiker met het systeem kan communiceren, zou je op een tegenstrijdigheid kunnen wijzen. Bedieningselementen, zoals knoppen op een webpagina of een virtueel toetsenbord op het scherm van een telefoon, maken in feite deel uit van de controller. Maar ze zijn net zo zichtbaar voor de gebruiker als elk ander deel van de weergave. Waar we het hier echt over hebben, is functionele scheiding. De belangrijkste taak van de gebruikersinterface is om de interactie van de gebruiker met het systeem te vergemakkelijken.
uitvoer en geeft systeeminformatie gemakkelijk weer aan de gebruiker
gebruikersgegevens en commando's invoeren (communiceren naar het systeem)
Deze functies bepalen hoe de gebruikersinterface in modules moet worden ingedeeld. Uiteindelijk ziet de systeemarchitectuur er zo uit: En zo komen we tot een applicatie die bestaat uit drie modules genaamd model, view en controller. Laten we samenvatten:
Volgens de principes van het MVC-paradigma moet een systeem worden opgedeeld in modules.
De belangrijkste en onafhankelijke module zou het model moeten zijn.
Het model is de kern van het systeem. Het moet mogelijk zijn om het onafhankelijk van de gebruikersinterface te ontwikkelen en te testen.
Om dit te bereiken, moeten we in de eerste stap van de divisie het systeem opsplitsen in een model en gebruikersinterface.
Vervolgens versterken we met behulp van het waarnemerspatroon de onafhankelijkheid van het model en synchroniseren we gebruikersinterfaces.
De derde stap is het verdelen van de gebruikersinterface in een controller en weergave.
Alles wat nodig is om gebruikersgegevens in het systeem te ontvangen, bevindt zich in de controller.
Alles wat nodig is om informatie aan de gebruiker te leveren, staat in de weergave.
Nog één belangrijk ding om te bespreken voordat je je warme chocolademelk kunt drinken.
Een beetje over hoe de view en controller omgaan met het model
Door informatie in te voeren via de controller verandert de gebruiker het model. Of in ieder geval verandert de gebruiker de modelgegevens. Wanneer de gebruiker informatie ontvangt via interface-elementen (via de weergave), ontvangt de gebruiker informatie over het model. Hoe gebeurde dit? Op welke manier interageren de weergave en de controller met het model? De klassen van de weergave kunnen immers niet rechtstreeks de methoden van de klassen van het model aanroepen om gegevens te lezen/schrijven. Anders zouden we niet kunnen zeggen dat het model onafhankelijk is. Het model is een set nauw verwante klassen waartoe noch de view, noch de controller toegang mag hebben. Om het model te verbinden met het zicht en de controller, moeten we het gevelontwerppatroon implementeren. De gevel van het model is de laag tussen het model en de gebruikersinterface, waardoor de weergave handig geformatteerde gegevens ontvangt en de controller gegevens wijzigt door de benodigde methoden op de gevel aan te roepen. Uiteindelijk ziet alles er zo uit:
MVC: Wat winnen we?
Het belangrijkste doel van het MVC-paradigma is om de implementatie van bedrijfslogica (het model) te scheiden van de visualisatie ervan (de weergave). Deze scheiding vergroot de mogelijkheden voor hergebruik van code. De voordelen van MVC zijn het duidelijkst wanneer we dezelfde gegevens in verschillende formaten moeten presenteren. Bijvoorbeeld als tabel, grafiek of diagram (met verschillende weergaven). Tegelijkertijd kunnen we, zonder invloed te hebben op de manier waarop weergaven worden geïmplementeerd, wijzigen hoe we reageren op gebruikersacties (klikken op knoppen, gegevensinvoer). Als u de principes van MVC volgt, kunt u softwareontwikkeling vereenvoudigen, de leesbaarheid van code vergroten en de uitbreidbaarheid en onderhoudbaarheid verbeteren. In het laatste artikel in de serie "Inleiding tot Enterprise Development" zullen we kijken naar een MVC-implementatie die is gebouwd met behulp van Spring MVC. Deel 8. Laten we een kleine applicatie schrijven met Spring Boot
In dit artikel leren we iets kennen dat MVC heet. We zullen het hebben over wat MVC is, de geschiedenis ervan bespreken, de basisideeën en -concepten verkennen die in MVC zijn belichaamd, stap voor stap bekijken hoe een applicatie kan worden opgedeeld in Model-, View- en Controller-modules, een kleine webapplicatie met behulp van Spring Boot en, met Spring MVC als voorbeeld, hoe gegevens van Java-code naar HTML-pagina's worden verzonden. Om dit materiaal te begrijpen, moet u bekend zijn met ontwerppatronen, met name waarnemer en gevel. En wees bekend met HTTP-verzoeken en -antwoorden, begrijp de basisprincipes van HTML en weet wat Java-annotaties zijn. Pak een kopje koffie en een snack en maak het je gemakkelijk. Laten we beginnen.
Uit dit alles kunnen we een logische conclusie trekken. Een complex systeem moet worden opgedeeld in modules. Laten we kort de stappen beschrijven om deze scheiding te bereiken.
En zo komen we tot een applicatie die bestaat uit drie modules genaamd model, view en controller. Laten we samenvatten:
GO TO FULL VERSION