Del 7. Introduktion av MVC-mönstret (Model-View-Controller).

Detta material är en del av serien "Introduktion till företagsutveckling". Tidigare artiklar:

• om nätverkande
• om mjukvaruarkitektur
• om HTTP/HTTPS
• om grunderna i Maven
• om servlets (att skriva en enkel webbapplikation)
• om servletbehållare

I den här artikeln kommer vi att lära känna något som kallas MVC. Vi kommer att prata om vad MVC är, beröra dess historia, utforska de grundläggande idéerna och koncepten som ingår i MVC, ta en steg-för-steg titt på hur man delar upp en applikation i modell-, vy- och kontrollmoduler, skriver en liten webbapplikation som använder Spring Boot, och med Spring MVC som exempel, se hur data skickas från Java-kod till HTML-sidor. För att förstå detta material måste du vara bekant med designmönster, särskilt observatör och fasad. Och vara bekant med HTTP-förfrågningar och svar, förstå grunderna i HTML och veta vad Java-anteckningar är. Ta en kopp kaffe och mellanmål och bli bekväm. Låt oss börja.

Historien om MVC

Idéerna bakom MVC formulerades av Trygve Reenskaug när han arbetade på Xerox PARC i slutet av 1970-talet. På den tiden krävde arbetet med datorer en examen och ständiga studier av omfattande dokumentation. Uppgiften som Reenskaug löste tillsammans med en grupp mycket starka utvecklare var att förenkla en vanlig användares interaktion med datorn. Det var nödvändigt att skapa verktyg som å ena sidan skulle vara extremt enkla och begripliga, och å andra sidan skulle göra det möjligt att styra datorer och komplexa applikationer. Reenskaug arbetade i ett team som utvecklade en bärbar dator "för barn i alla åldrar" — Dynabook, såväl som SmallTalk-språket under ledning av Alan Kay. Det var då konceptet för ett användarvänligt gränssnitt lades fast. I många avseenden, det arbete som utfördes av Reenskaug och hans team påverkade utvecklingen av IT-sfären. Här är ett intressant faktum som inte gäller MVC direkt, men som illustrerar betydelsen av denna utveckling. Alan Kaysa, "När jag först kom till Apple, vilket var 84, var Mac redan ute och Newsweek kontaktade mig och frågade mig vad jag tyckte om Macen. Jag sa:" Jo, Mac är den första persondatorn som är bra nog att bli kritiserad.' Så, efter att ha annonserat iPhone 2007, tog han fram den till mig och överlämnade den till mig. Han sa: "Alan, är den här tillräckligt bra för att bli kritiserad?" Och jag sa, 'Steve, gör den så här stor som en surfplatta så kommer du att styra världen'." Efter 3 år, den 27 januari 2010, introducerade Apple iPad med en diagonal på 9,7 tum. Steve Jobs följde med andra ord Alan Kays råd nästan exakt. Reenskaugs projekt varade i 10 år. Men den första publikationen om MVC kom fram efter ytterligare 10 år. Martin Fowler, författare till flera böcker och artiklar om mjukvaruarkitektur, nämner att han studerade MVC med en fungerande version av Smalltalk. Eftersom det inte fanns någon information om MVC från den ursprungliga källan under lång tid, och av flera andra skäl, dök ett stort antal olika tolkningar av detta koncept upp. Som ett resultat anser många att MVC är ett designmönster. Mindre vanligt kallas MVC för ett sammansatt mönster eller en kombination av flera mönster som samverkar för att skapa komplexa applikationer. Men, som tidigare nämnts, är MVC faktiskt i första hand en uppsättning arkitektoniska idéer/principer/tillvägagångssätt som kan implementeras på olika sätt med hjälp av olika mönster... Därefter ska vi överväga huvudidéerna som är inbäddade i MVC-konceptet. och av flera andra skäl dök ett stort antal olika tolkningar av detta begrepp upp. Som ett resultat anser många att MVC är ett designmönster. Mindre vanligt kallas MVC för ett sammansatt mönster eller en kombination av flera mönster som samverkar för att skapa komplexa applikationer. Men, som tidigare nämnts, är MVC faktiskt i första hand en uppsättning arkitektoniska idéer/principer/tillvägagångssätt som kan implementeras på olika sätt med hjälp av olika mönster... Därefter ska vi överväga huvudidéerna som är inbäddade i MVC-konceptet. och av flera andra skäl dök ett stort antal olika tolkningar av detta begrepp upp. Som ett resultat anser många att MVC är ett designmönster. Mindre vanligt kallas MVC för ett sammansatt mönster eller en kombination av flera mönster som samverkar för att skapa komplexa applikationer. Men, som tidigare nämnts, är MVC faktiskt i första hand en uppsättning arkitektoniska idéer/principer/tillvägagångssätt som kan implementeras på olika sätt med hjälp av olika mönster... Därefter ska vi överväga huvudidéerna som är inbäddade i MVC-konceptet.

MVC: Grundläggande idéer och principer

• VC är en uppsättning arkitektoniska idéer och principer för att bygga komplexa informationssystem med ett användargränssnitt
• MVC är en förkortning som står för: Model-View-Controller

Ansvarsfriskrivning: MVC är inte ett designmönster. MVC är en uppsättning arkitektoniska idéer och principer för att bygga komplexa system med ett användargränssnitt. Men för enkelhetens skull, för att inte upprepade gånger säga "en uppsättning arkitektoniska idéer ...", kommer vi att hänvisa till MVC-mönstret. Låt oss börja med det enkla. Vad döljer sig bakom orden Model-View-Controller? När du använder MVC-mönstret för att utveckla system med ett användargränssnitt måste du dela upp systemet i tre komponenter. De kan också kallas moduler eller komponenter. Kalla dem vad du vill, men dela upp systemet i tre komponenter. Varje komponent har sitt eget syfte. Modell. Den första komponenten/modulen kallas modellen. Den innehåller hela applikationens affärslogik. Se.Den andra delen av systemet är utsikten. Denna modul ansvarar för att visa data för användaren. Allt som användaren ser genereras av vyn. Kontroller.Den tredje länken i denna kedja är regulatorn. Den innehåller koden som är ansvarig för att hantera användaråtgärder (alla användaråtgärder hanteras i controllern). Modellen är den mest oberoende delen av systemet. Så oberoende att den inte får veta något om vyn och styrmoduler. Modellen är så oberoende att dess utvecklare kanske inte vet praktiskt taget ingenting om vyn och kontroller. Huvudsyftet med vyn är att tillhandahålla information från modellen i ett format som användaren kan konsumera. Synens främsta begränsning är att den inte får förändra modellen på något sätt. Huvudsyftet med regulatorn är att hantera användaråtgärder. Det är genom regulatorn som användaren gör ändringar i modellen. Eller mer exakt, till den data som finns lagrad i modellen. Här är diagrammet du såg tidigare i lektionen: Av allt detta kan vi dra en logisk slutsats. Ett komplext system måste delas upp i moduler. Låt oss kort beskriva stegen för att uppnå denna separation.

Steg 1. Separera programmets affärslogik från användargränssnittet

Huvudtanken med MVC är att alla applikationer med användargränssnitt kan delas in i 2 moduler: en modul som ansvarar för att implementera affärslogiken och användargränssnittet. Den första modulen kommer att implementera applikationens huvudfunktionalitet. Denna modul är kärnan i systemet, där applikationens domänmodell implementeras. I MVC-paradigmet är denna modul bokstaven M, dvs modellen. Den andra modulen implementerar hela användargränssnittet, inklusive logiken för att visa data för användaren och hantera användarinteraktion med applikationen. Huvudmålet med denna separation är att säkerställa att kärnan i systemet ("modellen" i MVC-terminologi) kan utvecklas och testas oberoende. Efter att ha gjort denna separation ser applikationens arkitektur ut så här:

Steg 2 Använd observatörsmönstret för att göra modellen ännu mer oberoende och för att synkronisera användargränssnitt

Här har vi 2 mål:

1. Uppnå ännu större oberoende för modellen
2. Synkronisera användargränssnitt

Följande exempel hjälper dig att förstå vad vi menar med synkronisering av användargränssnitt. Anta att vi köper en biobiljett online och ser antalet lediga platser på teatern. Samtidigt kanske någon annan köper en biobiljett. Om den här andra personen köper en biljett före oss, skulle vi vilja se en minskning av antalet tillgängliga platser för den showtime vi överväger. Låt oss nu fundera på hur detta kan implementeras inom ett program. Anta att vi har vårt systems kärna (vår modell) och gränssnitt (webbsidan för att köpa biljetter). Två användare försöker välja en plats på teatern samtidigt. Den första användaren köper en biljett. Webbsidan måste visa för den andra användaren att detta har hänt. Hur ska detta hända? Om vi ​​uppdaterar gränssnittet från kärnan, då kommer kärnan (vår modell) att vara beroende av gränssnittet. När vi utvecklar och testar modellen måste vi tänka på de olika sätten att uppdatera gränssnittet. För att uppnå detta måste vi implementera observatörsmönstret. Detta mönster låter modellen skicka ändringsmeddelanden till alla lyssnare. Som händelseavlyssnare (eller observatör) tar användargränssnittet emot meddelanden och uppdateras. Å ena sidan låter observatörsmönstret modellen informera gränssnittet (vy och styrenhet) om att förändringar har skett utan att faktiskt veta något om det, och förblir därmed oberoende. Å andra sidan gör det det möjligt att synkronisera användargränssnitt. vi måste implementera observatörsmönstret. Detta mönster låter modellen skicka ändringsmeddelanden till alla lyssnare. Som händelseavlyssnare (eller observatör) tar användargränssnittet emot meddelanden och uppdateras. Å ena sidan låter observatörsmönstret modellen informera gränssnittet (vy och styrenhet) om att förändringar har skett utan att faktiskt veta något om det, och förblir därmed oberoende. Å andra sidan gör det det möjligt att synkronisera användargränssnitt. vi måste implementera observatörsmönstret. Detta mönster låter modellen skicka ändringsmeddelanden till alla lyssnare. Som händelseavlyssnare (eller observatör) tar användargränssnittet emot meddelanden och uppdateras. Å ena sidan låter observatörsmönstret modellen informera gränssnittet (vy och styrenhet) om att förändringar har skett utan att faktiskt veta något om det, och förblir därmed oberoende. Å andra sidan gör det det möjligt att synkronisera användargränssnitt.

Steg 3 Separera gränssnittet i vy och styrenhet

Vi fortsätter att dela upp applikationen i moduler, men nu på en lägre nivå i hierarkin. I det här steget är användargränssnittet (som vi separerade i en distinkt modul i steg 1) uppdelat i en vy och en kontroller. Att dra en strikt linje mellan vyn och kontrollenheten är svårt. Om vi ​​säger att vyn är vad användaren ser, och kontrollern är mekanismen som gör att användaren kan interagera med systemet, kan du peka på en motsägelse. Kontrollelement, som knappar på en webbsida eller ett virtuellt tangentbord på telefonens skärm, är i princip en del av kontrollern. Men de är lika synliga för användaren som vilken del av vyn som helst. Vad vi egentligen pratar om här är funktionell separation. Användargränssnittets huvuduppgift är att underlätta användarens interaktion med systemet.

• mata ut och enkelt visa systeminformation för användaren
• ange användardata och kommandon (kommunicera dem till systemet)

Dessa funktioner bestämmer hur användargränssnittet ska delas upp i moduler. I slutändan ser systemarkitekturen ut så här: Och så kommer vi fram till en applikation som består av tre moduler som kallas modell, vy och styrenhet. Låt oss sammanfatta:

1. Enligt principerna för MVC-paradigmet måste ett system delas upp i moduler.
2. Den viktigaste och mest oberoende modulen bör vara modellen.
3. Modellen är kärnan i systemet. Det ska vara möjligt att utveckla och testa det oberoende av användargränssnittet.
4. För att uppnå detta måste vi i det första steget av uppdelningen dela upp systemet i en modell och ett användargränssnitt.
5. Sedan, med hjälp av observatörsmönstret, stärker vi modellens oberoende och synkroniserar användargränssnitt.
6. Det tredje steget är att dela upp användargränssnittet i en kontroller och vy.
7. Allt som krävs för att ta emot användardata i systemet finns i regulatorn.
8. Allt som krävs för att leverera information till användaren finns i vyn.

Bara en viktig sak till att diskutera innan du kan dricka din varma choklad.

Lite om hur vyn och kontroller interagerar med modellen

Genom att ange information via regulatorn ändrar användaren modell. Eller åtminstone ändrar användaren modelldata. När användaren får information via gränssnittselement (via vyn) får användaren information om modellen. Hur går det till? På vilka sätt samverkar vyn och styrenheten med modellen? Vyns klasser kan trots allt inte direkt anropa metoderna för modellens klasser för att läsa/skriva data. Annars skulle vi inte kunna säga att modellen är oberoende. Modellen är en uppsättning närbesläktade klasser som varken vyn eller regulatorn ska ha tillgång till. För att koppla modellen till vyn och styrenheten måste vi implementera fasaddesignmönstret. Modellens fasad är lagret mellan modellen och användargränssnittet, genom vilken vyn tar emot bekvämt formaterad data, och Controller ändrar data genom att anropa nödvändiga metoder på fasaden. I slutändan ser allt ut så här:

MVC: Vad vinner vi?

Huvudsyftet med MVC-paradigmet är att separera implementeringen av affärslogik (modellen) från dess visualisering (vyn). Denna separation ökar möjligheterna för kodåteranvändning. Fördelarna med MVC är mest uppenbara när vi behöver presentera samma data i olika format. Till exempel som en tabell, graf eller diagram (med olika vyer). Samtidigt kan vi, utan att påverka hur vyer implementeras, ändra hur vi reagerar på användaråtgärder (knappklick, datainmatning). Om du följer principerna för MVC kan du förenkla mjukvaruutvecklingen, öka kodläsbarheten och förbättra utbyggbarheten och underhållbarheten. I den sista artikeln i serien "Introduktion till företagsutveckling" kommer vi att titta på en MVC-implementation byggd med Spring MVC. Del 8. Låt oss skriva en liten applikation med Spring Boot