Del 7. Introduktion til MVC-mønsteret (Model-View-Controller).

Dette materiale er en del af serien "Introduktion til virksomhedsudvikling". Tidligere artikler:

• om netværk
• om softwarearkitektur
• om HTTP/HTTPS
• om det grundlæggende i Maven
• om servlets (skrivning af en simpel webapplikation)
• om servletbeholdere

I denne artikel lærer vi noget, der hedder MVC. Vi vil tale om, hvad MVC er, berøre dets historie, udforske de grundlæggende ideer og koncepter, der er inkorporeret i MVC, tage et trin-for-trin kig på, hvordan man deler en applikation op i Model-, View- og Controller-moduler, skrive en lille webapplikation, der bruger Spring Boot, og med Spring MVC som eksempel kan du se, hvordan data sendes fra Java-kode til HTML-sider. For at forstå dette materiale skal du være fortrolig med designmønstre, især observatør og facade. Og vær fortrolig med HTTP-anmodninger og -svar, forstå det grundlæggende i HTML, og ved, hvad Java-annoteringer er. Snup en kop kaffe og snack, og få det godt. Lad os begynde.

Historien om MVC

Idéerne bag MVC blev formuleret af Trygve Reenskaug, mens han arbejdede hos Xerox PARC i slutningen af ​​1970'erne. I de dage krævede arbejdet med computere en grad og konstant undersøgelse af omfangsrig dokumentation. Opgaven, som Reenskaug løste sammen med en gruppe meget stærke udviklere, var at forenkle en almindelig brugers interaktion med computeren. Det var nødvendigt at skabe værktøjer, der på den ene side ville være ekstremt enkle og forståelige, og på den anden side ville gøre det muligt at styre computere og komplekse applikationer. Reenskaug arbejdede på et team, der udviklede en bærbar computer "til børn i alle aldre" - Dynabook, såvel som SmallTalk-sproget under ledelse af Alan Kay. Det var dengang, koncepterne for en venlig grænseflade blev fastlagt. I mange henseender, arbejdet udført af Reenskaug og hans team påvirkede udviklingen af ​​IT-sfæren. Her er et interessant faktum, som ikke gælder for MVC direkte, men som illustrerer betydningen af ​​disse udviklinger. Alan Kaysagde, "Da jeg først kom til Apple, som var i '84, var Mac'en allerede ude, og Newsweek kontaktede mig og spurgte mig, hvad jeg syntes om Mac'en. Jeg sagde: 'Jamen, Mac'en er den første personlige computer, der er god nok til at blive kritiseret.' Så efter at have annonceret iPhonen i 2007, bragte han den til mig og gav mig den. Han sagde: "Alan, er det her godt nok til at blive kritiseret?" Og jeg sagde, 'Steve, gør den i denne størrelse så stor som en tablet, og du vil herske over verden.'" Efter 3 år, den 27. januar 2010, introducerede Apple iPad'en med en diagonal på 9,7 tommer. Steve Jobs fulgte med andre ord Alan Kays råd næsten nøjagtigt. Reenskaugs projekt varede i 10 år. Men den første udgivelse om MVC kom frem efter yderligere 10 år. Martin Fowler, forfatter til adskillige bøger og artikler om softwarearkitektur, nævner, at han studerede MVC ved hjælp af en fungerende version af Smalltalk. Fordi der ikke var nogen information om MVC fra den originale kilde i lang tid, og af flere andre årsager, dukkede et stort antal forskellige fortolkninger af dette koncept op. Som et resultat betragter mange MVC som et designmønster. Mindre almindeligt kaldes MVC et sammensat mønster eller en kombination af flere mønstre, der arbejder sammen for at skabe komplekse applikationer. Men, som tidligere nævnt, er MVC faktisk primært et sæt af arkitektoniske ideer/principper/tilgange, der kan implementeres på forskellige måder ved hjælp af forskellige mønstre... Dernæst vil vi overveje de vigtigste ideer, der er indlejret i MVC-konceptet. og af flere andre grunde dukkede et stort antal forskellige fortolkninger af dette koncept op. Som et resultat betragter mange MVC som et designmønster. Mindre almindeligt kaldes MVC et sammensat mønster eller en kombination af flere mønstre, der arbejder sammen for at skabe komplekse applikationer. Men, som tidligere nævnt, er MVC faktisk primært et sæt af arkitektoniske ideer/principper/tilgange, der kan implementeres på forskellige måder ved hjælp af forskellige mønstre... Dernæst vil vi overveje de vigtigste ideer, der er indlejret i MVC-konceptet. og af flere andre grunde dukkede et stort antal forskellige fortolkninger af dette koncept op. Som et resultat betragter mange MVC som et designmønster. Mindre almindeligt kaldes MVC et sammensat mønster eller en kombination af flere mønstre, der arbejder sammen for at skabe komplekse applikationer. Men, som tidligere nævnt, er MVC faktisk primært et sæt af arkitektoniske ideer/principper/tilgange, der kan implementeres på forskellige måder ved hjælp af forskellige mønstre... Dernæst vil vi overveje de vigtigste ideer, der er indlejret i MVC-konceptet.

MVC: Grundlæggende ideer og principper

• VC er et sæt arkitektoniske ideer og principper til at bygge komplekse informationssystemer med en brugergrænseflade
• MVC er en forkortelse, der står for: Model-View-Controller

Ansvarsfraskrivelse: MVC er ikke et designmønster. MVC er et sæt arkitektoniske ideer og principper til at bygge komplekse systemer med en brugergrænseflade. Men for nemheds skyld, for ikke gentagne gange at sige "et sæt arkitektoniske ideer ...", vil vi henvise til MVC-mønsteret. Lad os starte med det enkle. Hvad gemmer sig bag ordene Model-View-Controller? Når du bruger MVC-mønsteret til at udvikle systemer med en brugergrænseflade, skal du opdele systemet i tre komponenter. De kan også kaldes moduler eller komponenter. Kald dem hvad du vil, men del systemet op i tre komponenter. Hver komponent har sit eget formål. Model. Den første komponent/modul kaldes modellen. Den indeholder hele applikationens forretningslogik. Udsigt.Den anden del af systemet er udsigten. Dette modul er ansvarlig for at vise data til brugeren. Alt, hvad brugeren ser, genereres af visningen. Controller.Det tredje led i denne kæde er controlleren. Den indeholder koden, der er ansvarlig for håndtering af brugerhandlinger (alle brugerhandlinger håndteres i controlleren). Modellen er den mest uafhængige del af systemet. Så uafhængig, at den ikke må vide noget om visningen og controller-modulerne. Modellen er så uafhængig, at dens udviklere næsten ikke ved noget om visningen og controlleren. Hovedformålet med visningen er at give information fra modellen i et format, som brugeren kan forbruge. Synets væsentligste begrænsning er, at det ikke må ændre modellen på nogen måde. Hovedformålet med controlleren er at håndtere brugerhandlinger. Det er gennem controlleren, at brugeren foretager ændringer i modellen. Eller mere præcist til de data, der er gemt i modellen. Her er det diagram, du så tidligere i lektionen: Ud fra alt dette kan vi drage en logisk konklusion. Et komplekst system skal opdeles i moduler. Lad os kort beskrive trinene for at opnå denne adskillelse.

Trin 1. Adskil applikationens forretningslogik fra brugergrænsefladen

Hovedideen med MVC er, at enhver applikation med en brugergrænseflade kan opdeles i 2 moduler: et modul, der er ansvarlig for implementering af forretningslogikken, og brugergrænsefladen. Det første modul vil implementere applikationens hovedfunktionalitet. Dette modul er kernen i systemet, hvor applikationens domænemodel er implementeret. I MVC-paradigmet er dette modul bogstavet M, altså modellen. Det andet modul implementerer hele brugergrænsefladen, inklusive logikken til at vise data til brugeren og håndtere brugerinteraktion med applikationen. Hovedmålet med denne adskillelse er at sikre, at kernen i systemet ("modellen" i MVC-terminologi) kan udvikles og testes selvstændigt. Efter at have foretaget denne adskillelse ser applikationens arkitektur således ud:

Trin 2 Brug observatørmønsteret til at gøre modellen endnu mere uafhængig og til at synkronisere brugergrænseflader

Her har vi 2 mål:

1. Opnå endnu større uafhængighed for modellen
2. Synkroniser brugergrænseflader

Følgende eksempel hjælper dig med at forstå, hvad vi mener med synkronisering af brugergrænseflader. Antag, at vi køber en biografbillet online og ser antallet af ledige pladser i biografen. Samtidig er der måske en anden, der køber en biografbillet. Hvis denne anden person køber en billet før os, vil vi gerne se et fald i antallet af ledige pladser til det showtime, vi overvejer. Lad os nu tænke på, hvordan dette kan implementeres i et program. Antag, at vi har vores systems kerne (vores model) og interface (websiden til køb af billetter). To brugere forsøger at vælge en plads i teatret samtidigt. Den første bruger køber en billet. Websiden skal vise den anden bruger, at dette er sket. Hvordan skal dette ske? Hvis vi opdaterer grænsefladen fra kernen, så vil kernen (vores model) være afhængig af grænsefladen. Når vi udvikler og tester modellen, bliver vi nødt til at huske på de forskellige måder at opdatere grænsefladen på. For at opnå dette skal vi implementere observatørmønsteret. Dette mønster lader modellen sende ændringsmeddelelser til alle lyttere. Som hændelseslytter (eller observatør) modtager brugergrænsefladen meddelelser og opdateres. På den ene side lader observatørmønsteret modellen informere grænsefladen (view og controller) om, at der er sket ændringer uden egentlig at vide noget om det, og dermed forblive uafhængig. På den anden side gør det det muligt at synkronisere brugergrænseflader. vi skal implementere observatørmønsteret. Dette mønster lader modellen sende ændringsmeddelelser til alle lyttere. Som hændelseslytter (eller observatør) modtager brugergrænsefladen meddelelser og opdateres. På den ene side lader observatørmønsteret modellen informere grænsefladen (view og controller) om, at der er sket ændringer uden egentlig at vide noget om det, og dermed forblive uafhængig. På den anden side gør det det muligt at synkronisere brugergrænseflader. vi skal implementere observatørmønsteret. Dette mønster lader modellen sende ændringsmeddelelser til alle lyttere. Som hændelseslytter (eller observatør) modtager brugergrænsefladen meddelelser og opdateres. På den ene side lader observatørmønsteret modellen informere grænsefladen (view og controller) om, at der er sket ændringer uden egentlig at vide noget om det, og dermed forblive uafhængig. På den anden side gør det det muligt at synkronisere brugergrænseflader.

Trin 3 Adskil grænsefladen i visning og controller

Vi fortsætter med at opdele applikationen i moduler, men nu på et lavere niveau i hierarkiet. På dette trin er brugergrænsefladen (som vi adskilte i et særskilt modul i trin 1) opdelt i en visning og en controller. Det er svært at trække en streng linje mellem visningen og controlleren. Hvis vi siger, at visningen er, hvad brugeren ser, og controlleren er den mekanisme, der tillader brugeren at interagere med systemet, kan du påpege en selvmodsigelse. Kontrolelementer, såsom knapper på en webside eller et virtuelt tastatur på en telefons skærm, er grundlæggende en del af controlleren. Men de er lige så synlige for brugeren som enhver del af visningen. Det, vi egentlig taler om her, er funktionel adskillelse. Brugergrænsefladens hovedopgave er at lette brugerens interaktion med systemet.

• output og bekvemt vise systeminformation til brugeren
• indtast brugerdata og kommandoer (kommuniker dem til systemet)

Disse funktioner bestemmer, hvordan brugergrænsefladen skal opdeles i moduler. I sidste ende ser systemarkitekturen således ud: Og sådan kommer vi frem til en applikation bestående af tre moduler kaldet model, view og controller. Lad os opsummere:

1. Ifølge principperne i MVC-paradigmet skal et system opdeles i moduler.
2. Det vigtigste og mest uafhængige modul bør være modellen.
3. Modellen er kernen i systemet. Det skal være muligt at udvikle og teste det uafhængigt af brugergrænsefladen.
4. For at opnå dette skal vi i det første trin af opdelingen opdele systemet i en model og brugergrænseflade.
5. Derefter, ved hjælp af observatørmønsteret, styrker vi modellens uafhængighed og synkroniserer brugergrænseflader.
6. Det tredje trin er at opdele brugergrænsefladen i en controller og visning.
7. Alt hvad der kræves for at modtage brugerdata ind i systemet er i controlleren.
8. Alt hvad der kræves for at levere information til brugeren er i visningen.

Bare endnu en vigtig ting at diskutere, før du kan drikke din varme chokolade.

Lidt om hvordan visningen og controlleren interagerer med modellen

Ved at indtaste oplysninger gennem controlleren ændrer brugeren model. Eller i det mindste ændrer brugeren modeldataene. Når brugeren modtager information gennem interface-elementer (via visningen), modtager brugeren information om modellen. Hvordan sker dette? Med hvilke midler interagerer visningen og controlleren med modellen? Visningens klasser kan jo ikke direkte kalde metoderne i modellens klasser til at læse/skrive data. Ellers ville vi ikke kunne sige, at modellen er uafhængig. Modellen er et sæt af nært beslægtede klasser, som hverken visningen eller controlleren skal have adgang til. For at forbinde modellen med udsigten og controlleren skal vi implementere facadedesignmønsteret. Modellens facade er laget mellem modellen og brugerfladen, hvorigennem visningen modtager bekvemt formaterede data, og controlleren ændrer data ved at kalde de nødvendige metoder på facaden. I sidste ende ser alt sådan her ud:

MVC: Hvad vinder vi?

Hovedformålet med MVC-paradigmet er at adskille implementeringen af ​​forretningslogik (modellen) fra dens visualisering (udsigten). Denne adskillelse øger mulighederne for genbrug af kode. Fordelene ved MVC er mest tydelige, når vi skal præsentere de samme data i forskellige formater. For eksempel som en tabel, graf eller diagram (ved brug af forskellige visninger). Samtidig kan vi, uden at påvirke hvordan visninger implementeres, ændre, hvordan vi reagerer på brugerhandlinger (knapklik, dataindtastning). Hvis du følger principperne for MVC, kan du forenkle softwareudvikling, øge kodelæsbarheden og forbedre udvidelsesmuligheder og vedligeholdelse. I den sidste artikel i serien "Introduktion til virksomhedsudvikling" vil vi se på en MVC-implementering bygget ved hjælp af Spring MVC. Del 8. Lad os skrive en lille ansøgning ved hjælp af Spring Boot