Del
MVC – Det grundlæggende

MVC – Det grundlæggende

Da artiklen her er rettet mod voksne i stil med dem der går på en erhvervsudannelse eller lignende er tonen i den tilpasset den målgruppe ud fra mine egne erfaringer dermed.

Artiklen er også kun tænkt som en kort introduktion til emnet, der findes langt mere uddybende tekster på engelsk.

Introduktion

MVC, forkortelsen for Model View Controller men i daglig tale kalder alle jeg kender det blot MVC, er et designmønster for software tilbage fra 1970erne. Modellen blev oprindeligt brugt til at designe software med et grafisk interface ud fra, men er i dag blevet utroligt populær til web applikationer også – omend man kan diskutere om den bruges i den oprindelige udformning, især da der er forskellige måder at fordele ansvaret mellem klienten og serveren1.

Teorien

MVC deler software applikationen op i tre forbundne dele, så den interne repræsentation af data adskilles fra det der modtages fra og vises til brugeren.

Det er vigtigt at have i mente at MVC ikke er et framework i sig selv, omend der er mange frameworks der benytter tankegangen, det er “blot” et mønster til strukturel opbygning og dermed udvikling af software.

Modellen
Her taler vi desværre ikke om en veldrejet undertøjs-model for Victorias Secrets men den kode som lagrer data, der er hentet i henhold til kommandoer fra controlleren og vises i view’et. Modellen udfører altså det arbejde der gør at hjemmesiden/softwaren reelt har en funktion og ser ikke bare pæn ud.

Viewet
Her er der igen ikke tale om et billede af den førnævnte model men den kode der skaber en output præsentation for brugeren baseret på ændringer i modellen. Den grafiske overfalde på hjemmesiden eller softwaren som gør den lækker at bruge. Det er vigtigt at notere at view ikke er templates men klasser og metoder.

Controlleren
Controlleren kan sende kommandoer til modellen, opdatere modellens tilstand (f.eks at redigere et dokument). Det kan også sende kommandoer til dens tilhørende view for at ændre visningen af modellen (fx ved at scrolle gennem et dokument). Det er her man definerer de grundlæggende funktioner i ens hjemmeside / software som database forbindelse.

MVC definerer altså en struktur for den måde man opbygger sin software på, hvor man lægger de forskellige funktioner i ens kode, hvilket gør den mere overskuelig både for en selv og for andre. På den måde er den også en objekt orienteret tankegang, da man netop definerer objekter i de forskellige “lag” som man så henviser til og benytter de andre steder.

Ting der bruger MVC

Siden jeg har mest erfaring med webudvikling er eksemplerne være baseret på dette felt

Der er som nævnt i introduktionen mange frameworks der benytter MVC tankegangen, dette er blot et udpluk af nogle af de mest populære:

  • Ruby on Rails, eller bare Rails, er et web applikations framework skrevet i Ruby. Det følger MVC standarden da det har en standard strukturer for database, webtjeneste og web-sider.

  • Django er et web applikations framework skrevet i Python hvis formål er at lette skabelsen af komplekse, database drevne hjemmesider. Django følger MVC standarden da de består af en objekt-relational mapper (ORM), der medierer mellem datamodeller (defineret som Python klasser) og en relationel database (“Model”); et system til behandling af HTTP-forespørgsler med et web-templating-system (“View”) og en regular-expression-baseret URL afsender (“Controller”).

  • Express.js er et node.js web applikationsserver framework, der er designet til hjemmesider og hybrid webapplikationer. Det er de facto standard server rammer for node.js, og den er en del af MEAN software stakken (MongoDB,  Express, AngularJS og det hele kører på NodeJStil dynamiske hjemmesider og webapplikationer.

Fælles for disse er at de alle kan kaldes for en slags tynde klienter, da brugeren sender enten hyperlinks eller form input til webserveren, hvor controlleren er, og får en komplet hjemmeside igen, modellen er altså kun på serveren.

Nyere frameworks lader dele af modellen køre på brugerens computer, nu hvor teknologierne er mere modne, et meget udbredt eksempel er Angular.js

Angular.js læser HTML-siden, der har indlejret ekstra attributter. Angular fortolker disse attributter som regler der binder input eller output dele af siden til en model, der er repræsenteret ved standard JavaScript variabler. Værdierne af disse JavaScript variabler kan indstilles manuelt i koden, eller hentes fra statiske eller dynamiske JSON ressourcer. Ved hjælp af dette flytter Angular traditionelle server-side-tjenester, såsom visnings-afhængige controllere, til klient-side web-applikationerne og reducerer derved en stor del af byrden på serveren.

MVC tankegangen er også benyttet i flere udviklings værktøjer og miljøer til apps til mobil-telefoner, et eksempel herpå er Appcelerator.

Er det MVC af navn eller af gavn

Der er udover eksemplerne ovenfor en række web framework systemer, bl.a. i PHP, som jeg dog har set en del debat om man kan kalde rigtig MVC da det kan diskuteres hvor dybdegående de opfylder modellen. Denne debat vil dog mere høre hjemme i vurderinger af de enkelte frameworks frem for i en generel introduktion til MVC.

Mange web frameworks regner f.eks. også View delen som mere eller mindre separeret, ekstern theming og ikke som en definition af variablerne, der bestemmer selve grund-opbygningen af siden.


Tilfældet Appcelerator

Dette indlæg udspringer oprindeligt af en bachelor-opgave, hvori der blev benyttet programmet Appcelerator til at lave mobil-apps, så derfor har jeg en udvidet sektion om netop dette programs vinkel på MVC.

Appcelerator (tidligere Titanium) benytter i sin Alloy del MVC strukturen. Man er ikke tvunget til at følge en MVC struktur i Appcelerator Studio, og så alligevel, for hvis man bruger klassisk kodning kan man kode ret frit2, men hvis man bruger Alloy benyttes der en struktur baseret på MVC tanken3.

Det er vigtigt at huske at hver “side” i ens app har et separat sæt filer i hver mappe, men der er et universelt fil-sæt kaldet app.respektivt-filnavn-efter-mappen der dækker det hele som standard. Man kan dog føje ekstra funktiones-filer til models og controllers og så kalde dem. Mange laver dog også flere sider i deres app som views frem for separate sider, hvilket passer godt ind i denne struktur.

I models mappen ligger de filer, der behandler den data, vi har fået gennem variabler defineret i controlleren.
XML-filerne4 i views mappen definerer strukturen på udseendet, hvilket igen er en funktionel beskrivelse per MVC standarden, medens man skriver hvordan udseendet reelt ser ud i TSS-filerne5 i styles mappen, altså theming som nogle web udviklere kalder for view delen6.
controllers mappen indeholder de funktioner, der giver den overordnede app, og de specifkke sider derunder som beskrevet ovenfor, den funktionalitet der ønskes. Det defineres her og bliver så eventuelt bearbejdes af modellerne7 og fremvises i view’et, der danner den brugerflade brugeren af app’en ser. Når brugeren så klikker på en knap eller på anden måde interagerer fanger kode i controlleren så dette og forløbet starter på ny.


Litteratur

  • Leff, Avraham; Rayfield, James T. (2001). Web-Application Development Using the Model/View/ Controller Design Pattern. IEEE Enterprise Distributed Object Computing Conference. Side 118– 127.
  • Sounders, Aaron (2015). Building Crossplatform apps Using Titanium, Alloy, and Appcelerator Cloud Services. Wiley. Side 43-81
  1.  Leff, Rayfield
  2.  Alle objekter skal defineres i en variabel, men strukturen er ikke fast
  3. Sounders
  4.  Appcelerator bruger en tilpasset variant af XML til dette
  5.  TSS (Titanium StyleSheet) er et sprog, der er en adaption af CSS (Cascading StyleSheets) med få ændringer
  6.  Derfor kaldes denne opbygning af nogen for MCT (mode controller theming), men normalt regnes det bare for en variation over MVC mønsteret
  7.  Det er ikke et krav at man har noget i model-mappen, hvilket gør at Appcelerator kun bruger CV delen af modellen, hvilket udviklingsmiljøet ikke har nogen problemer med

Skriv en kommentar