Del 7. Vi introduserer MVC-mønsteret (Model-View-Controller).

Dette materialet er en del av serien "Introduksjon til bedriftsutvikling". Tidligere artikler:

• om nettverk
• om programvarearkitektur
• om HTTP/HTTPS
• om det grunnleggende om Maven
• om servlets (skrive en enkel nettapplikasjon)
• om servletbeholdere

I denne artikkelen skal vi bli kjent med noe som heter MVC. Vi skal snakke om hva MVC er, berøre historien, utforske de grunnleggende ideene og konseptene som er nedfelt i MVC, ta en steg-for-steg titt på hvordan du deler opp en applikasjon i modell-, visnings- og kontrollermoduler, skriver en liten nettapplikasjon som bruker Spring Boot, og ved å bruke Spring MVC som eksempel, se hvordan data sendes fra Java-kode til HTML-sider. For å forstå dette materialet, må du være kjent med designmønstre, spesielt observatør og fasade. Og bli kjent med HTTP-forespørsler og svar, forstå det grunnleggende om HTML og vite hva Java-merknader er. Ta en kopp kaffe og matbit, og bli komfortabel. La oss begynne.

Historien om MVC

Ideene bak MVC ble formulert av Trygve Reenskaug mens han jobbet ved Xerox PARC på slutten av 1970-tallet. På den tiden krevde arbeidet med datamaskiner en grad og konstant studie av omfangsrik dokumentasjon. Oppgaven løst av Reenskaug sammen med en gruppe meget sterke utviklere var å forenkle en vanlig brukers interaksjon med datamaskinen. Det var nødvendig å lage verktøy som på den ene siden skulle være ekstremt enkle og forståelige, og på den andre siden gjøre det mulig å kontrollere datamaskiner og komplekse applikasjoner. Reenskaug jobbet på et team som utviklet en bærbar datamaskin "for barn i alle aldre" - Dynabook, samt SmallTalk-språket under ledelse av Alan Kay. Det var da konseptene for et vennlig grensesnitt ble lagt ned. På mange måter, arbeidet utført av Reenskaug og teamet hans påvirket utviklingen av IT-sfæren. Her er et interessant faktum som ikke gjelder MVC direkte, men som illustrerer betydningen av denne utviklingen. Alan Kaysa, "Da jeg først kom til Apple, som var i 84, var Mac-en allerede ute og Newsweek kontaktet meg og spurte meg hva jeg syntes om Mac-en. Jeg sa: Vel, Mac-en er den første personlige datamaskinen som er god nok til å bli kritisert.' Så, etter å ha annonsert iPhone i 2007, tok han den opp til meg og ga den til meg. Han sa: 'Alan, er dette bra nok til å bli kritisert?' Og jeg sa: «Steve, gjør den i denne størrelsen like stor som et nettbrett, og du vil styre verden.» Etter 3 år, 27. januar 2010, introduserte Apple iPad med en diagonal på 9,7 tommer. Steve Jobs fulgte med andre ord Alan Kays råd nesten nøyaktig. Reenskaugs prosjekt varte i 10 år. Men den første publikasjonen om MVC kom frem etter ytterligere 10 år. Martin Fowler, forfatter av flere bøker og artikler om programvarearkitektur, nevner at han studerte MVC ved å bruke en fungerende versjon av Smalltalk. Fordi det ikke var informasjon om MVC fra den opprinnelige kilden på lenge, og av flere andre grunner, dukket det opp et stort antall forskjellige tolkninger av dette konseptet. Som et resultat anser mange MVC for å være et designmønster. Mindre vanlig kalles MVC et sammensatt mønster eller en kombinasjon av flere mønstre som fungerer sammen for å lage komplekse applikasjoner. Men, som nevnt tidligere, er MVC faktisk først og fremst et sett med arkitektoniske ideer/prinsipper/tilnærminger som kan implementeres på ulike måter ved å bruke forskjellige mønstre... Deretter skal vi vurdere hovedideene som er innebygd i MVC-konseptet. og av flere andre grunner dukket det opp et stort antall forskjellige tolkninger av dette konseptet. Som et resultat anser mange MVC for å være et designmønster. Mindre vanlig kalles MVC et sammensatt mønster eller en kombinasjon av flere mønstre som fungerer sammen for å lage komplekse applikasjoner. Men, som nevnt tidligere, er MVC faktisk først og fremst et sett med arkitektoniske ideer/prinsipper/tilnærminger som kan implementeres på ulike måter ved å bruke forskjellige mønstre... Deretter skal vi vurdere hovedideene som er innebygd i MVC-konseptet. og av flere andre grunner dukket det opp et stort antall forskjellige tolkninger av dette konseptet. Som et resultat anser mange MVC for å være et designmønster. Mindre vanlig kalles MVC et sammensatt mønster eller en kombinasjon av flere mønstre som fungerer sammen for å lage komplekse applikasjoner. Men, som nevnt tidligere, er MVC faktisk først og fremst et sett med arkitektoniske ideer/prinsipper/tilnærminger som kan implementeres på ulike måter ved å bruke forskjellige mønstre... Deretter skal vi vurdere hovedideene som er innebygd i MVC-konseptet.

MVC: Grunnleggende ideer og prinsipper

• VC er et sett med arkitektoniske ideer og prinsipper for å bygge komplekse informasjonssystemer med et brukergrensesnitt
• MVC er en forkortelse som står for: Model-View-Controller

Ansvarsfraskrivelse: MVC er ikke et designmønster. MVC er et sett med arkitektoniske ideer og prinsipper for å bygge komplekse systemer med et brukergrensesnitt. Men for enkelhets skyld, for å ikke gjentatte ganger si "et sett med arkitektoniske ideer ...", vil vi referere til MVC-mønsteret. La oss starte med det enkle. Hva skjuler seg bak ordene Model-View-Controller? Når du bruker MVC-mønsteret til å utvikle systemer med brukergrensesnitt, må du dele systemet inn i tre komponenter. De kan også kalles moduler eller komponenter. Kall dem hva du vil, men del systemet inn i tre komponenter. Hver komponent har sitt eget formål. Modell. Den første komponenten/modulen kalles modellen. Den inneholder all applikasjonens forretningslogikk. Utsikt.Den andre delen av systemet er utsikten. Denne modulen er ansvarlig for å vise data til brukeren. Alt som brukeren ser genereres av visningen. Kontroller.Det tredje leddet i denne kjeden er kontrolleren. Den inneholder koden som er ansvarlig for å håndtere brukerhandlinger (alle brukerhandlinger håndteres i kontrolleren). Modellen er den mest uavhengige delen av systemet. Så uavhengig at den ikke må vite noe om visningen og kontrollermodulene. Modellen er så uavhengig at utviklerne kan nesten ikke vite noe om visningen og kontrolleren. Hovedformålet med visningen er å gi informasjon fra modellen i et format som brukeren kan konsumere. Synets hovedbegrensning er at det ikke må endre modellen på noen måte. Hovedformålet med kontrolleren er å håndtere brukerhandlinger. Det er gjennom kontrolleren at brukeren gjør endringer i modellen. Eller mer presist til dataene som er lagret i modellen. Her er diagrammet du så tidligere i leksjonen: Fra alt dette kan vi trekke en logisk konklusjon. Et komplekst system må deles inn i moduler. La oss kort beskrive trinnene for å oppnå denne separasjonen.

Trinn 1. Skill applikasjonens forretningslogikk fra brukergrensesnittet

Hovedideen til MVC er at enhver applikasjon med brukergrensesnitt kan deles inn i 2 moduler: en modul som er ansvarlig for å implementere forretningslogikken, og brukergrensesnittet. Den første modulen vil implementere applikasjonens hovedfunksjonalitet. Denne modulen er kjernen i systemet, hvor applikasjonens domenemodell er implementert. I MVC-paradigmet er denne modulen bokstaven M, altså modellen. Den andre modulen implementerer hele brukergrensesnittet, inkludert logikken for å vise data til brukeren og håndtere brukerinteraksjon med applikasjonen. Hovedmålet med denne separasjonen er å sikre at kjernen i systemet ("modellen" i MVC-terminologi) kan utvikles og testes uavhengig. Etter å ha gjort denne separasjonen, ser applikasjonens arkitektur slik ut:

Trinn 2 Bruk observatørmønsteret for å gjøre modellen enda mer uavhengig og for å synkronisere brukergrensesnitt

Her har vi 2 mål:

1. Oppnå enda større uavhengighet for modellen
2. Synkroniser brukergrensesnitt

Følgende eksempel vil hjelpe deg å forstå hva vi mener med synkronisering av brukergrensesnitt. Tenk deg at vi kjøper en kinobillett på nettet og ser antall ledige seter i kinoen. Samtidig kan det hende at noen andre kjøper en kinobillett. Hvis denne andre personen kjøper billett før oss, vil vi gjerne se en nedgang i antall ledige plasser for visningstiden vi vurderer. La oss nå tenke på hvordan dette kan implementeres i et program. Anta at vi har systemets kjerne (modellen vår) og grensesnittet (nettsiden for kjøp av billetter). To brukere prøver å velge en plass i teateret samtidig. Den første brukeren kjøper en billett. Nettsiden må vise den andre brukeren at dette har skjedd. Hvordan skal dette skje? Hvis vi oppdaterer grensesnittet fra kjernen, da vil kjernen (vår modell) være avhengig av grensesnittet. Når vi utvikler og tester modellen, må vi huske på de ulike måtene å oppdatere grensesnittet på. For å oppnå dette må vi implementere observatørmønsteret. Dette mønsteret lar modellen sende endringsvarsler til alle lyttere. Som en hendelseslytter (eller observatør) mottar brukergrensesnittet varsler og oppdateres. På den ene siden lar observatørmønsteret modellen informere grensesnittet (visning og kontroller) om at endringer har skjedd uten å faktisk vite noe om det, og dermed forbli uavhengig. På den annen side gjør det det mulig å synkronisere brukergrensesnitt. vi må implementere observatørmønsteret. Dette mønsteret lar modellen sende endringsvarsler til alle lyttere. Som en hendelseslytter (eller observatør) mottar brukergrensesnittet varsler og oppdateres. På den ene siden lar observatørmønsteret modellen informere grensesnittet (visning og kontroller) om at endringer har skjedd uten å faktisk vite noe om det, og dermed forbli uavhengig. På den annen side gjør det det mulig å synkronisere brukergrensesnitt. vi må implementere observatørmønsteret. Dette mønsteret lar modellen sende endringsvarsler til alle lyttere. Som en hendelseslytter (eller observatør) mottar brukergrensesnittet varsler og oppdateres. På den ene siden lar observatørmønsteret modellen informere grensesnittet (visning og kontroller) om at endringer har skjedd uten å faktisk vite noe om det, og dermed forbli uavhengig. På den annen side gjør det det mulig å synkronisere brukergrensesnitt.

Trinn 3 Separer grensesnittet i visning og kontroller

Vi fortsetter å dele opp applikasjonen i moduler, men nå på et lavere nivå i hierarkiet. På dette trinnet er brukergrensesnittet (som vi delte inn i en distinkt modul i trinn 1) delt inn i en visning og en kontroller. Det er vanskelig å trekke en streng linje mellom visningen og kontrolleren. Hvis vi sier at utsikten er det brukeren ser, og kontrolleren er mekanismen som lar brukeren samhandle med systemet, kan du påpeke en selvmotsigelse. Kontrollelementer, som knapper på en nettside eller et virtuelt tastatur på telefonens skjerm, er i utgangspunktet en del av kontrolleren. Men de er like synlige for brukeren som alle deler av visningen. Det vi egentlig snakker om her er funksjonell separasjon. Brukergrensesnittets hovedoppgave er å lette brukerens interaksjon med systemet.

• ut og enkelt vise systeminformasjon til brukeren
• skriv inn brukerdata og kommandoer (kommuniser dem til systemet)

Disse funksjonene bestemmer hvordan brukergrensesnittet skal deles inn i moduler. Til slutt ser systemarkitekturen slik ut: Og slik kommer vi frem til en applikasjon bestående av tre moduler kalt modell, visning og kontroller. La oss oppsummere:

1. I henhold til prinsippene i MVC-paradigmet må et system deles inn i moduler.
2. Den viktigste og mest uavhengige modulen bør være modellen.
3. Modellen er kjernen i systemet. Det skal være mulig å utvikle og teste det uavhengig av brukergrensesnittet.
4. For å oppnå dette, i det første trinnet i delingen, må vi dele opp systemet i en modell og brukergrensesnitt.
5. Deretter, ved hjelp av observatørmønsteret, styrker vi modellens uavhengighet og synkroniserer brukergrensesnitt.
6. Det tredje trinnet er å dele brukergrensesnittet inn i en kontroller og visning.
7. Alt som kreves for å motta brukerdata inn i systemet er i kontrolleren.
8. Alt som kreves for å levere informasjon til brukeren er i visningen.

Bare en viktig ting til å diskutere før du kan drikke den varme sjokoladen.

Litt om hvordan visningen og kontrolleren samhandler med modellen

Ved å legge inn informasjon gjennom kontrolleren, endrer brukeren modell. Eller i det minste endrer brukeren modelldataene. Når brukeren mottar informasjon gjennom grensesnittelementer (via visningen), mottar brukeren informasjon om modellen. Hvordan skjer dette? På hvilke måter samhandler visningen og kontrolleren med modellen? Tross alt kan ikke visningens klasser direkte kalle metodene til modellens klasser for å lese/skrive data. Ellers ville vi ikke kunne si at modellen er uavhengig. Modellen er et sett med nært beslektede klasser som verken visningen eller kontrolleren skal ha tilgang til. For å koble modellen til utsikten og kontrolleren, må vi implementere fasadedesignmønsteret. Modellens fasade er laget mellom modellen og brukergrensesnittet, der visningen mottar praktisk formaterte data, og kontrolleren endrer data ved å kalle de nødvendige metodene på fasaden. Til slutt ser alt slik ut:

MVC: Hva får vi?

Hovedmålet med MVC-paradigmet er å skille implementeringen av forretningslogikk (modellen) fra visualiseringen (visningen). Denne separasjonen øker mulighetene for gjenbruk av kode. Fordelene med MVC er tydeligst når vi trenger å presentere de samme dataene i forskjellige formater. For eksempel som en tabell, graf eller diagram (ved bruk av forskjellige visninger). Samtidig, uten å påvirke hvordan visninger implementeres, kan vi endre hvordan vi reagerer på brukerhandlinger (knappeklikk, dataregistrering). Hvis du følger prinsippene til MVC, kan du forenkle programvareutvikling, øke kodelesbarheten og forbedre utvidbarhet og vedlikehold. I den siste artikkelen i serien "Introduksjon til bedriftsutvikling" skal vi se på en MVC-implementering bygget ved hjelp av Spring MVC. Del 8. La oss skrive en liten applikasjon med Spring Boot