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
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
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:- Uppnå ännu större oberoende för modellen
- 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)
- Enligt principerna för MVC-paradigmet måste ett system delas upp i moduler.
- Den viktigaste och mest oberoende modulen bör vara modellen.
- Modellen är kärnan i systemet. Det ska vara möjligt att utveckla och testa det oberoende av användargränssnittet.
- 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.
- Sedan, med hjälp av observatörsmönstret, stärker vi modellens oberoende och synkroniserar användargränssnitt.
- Det tredje steget är att dela upp användargränssnittet i en kontroller och vy.
- Allt som krävs för att ta emot användardata i systemet finns i regulatorn.
- Allt som krävs för att leverera information till användaren finns i vyn.
GO TO FULL VERSION