Dag 1 - osadi/yrgo GitHub Wiki

MVC

Vad är MVC?

The central idea behind MVC is code reusability and separation of concerns.

MVC är en förkortning på Model View Controller och är ett Architectural Pattern. Var är då ett Architectural Pattern? Det är en definition på ett sätt att lösa ett vanligt återkommande problem. MVC är alltså ett sätt att beskriva hur man på ett sätt löser problemet med att implementera ett GUI.

Om man följer MVC under utvecklingen av sin applikation så får man en applikation med delar i den som har väldefinierade roller. Varje del är ansvarig för en sak, och blir samtidigt en mindre enhet som är lättare att underhålla och överblicka. Vi får även delar som går att återanvända. Och det är något som vi vill eftersträva i varje applikation. DRY, eller Don't Repeat Yourself, gör att vi bara ett ställe att underhålla samma funktionalitet på. Vi behöver inte heller lägga tid på att skriva samma kodstycke igen.

Allt detta gör så att det blir lätt att byta ut eller förändra utvalda delar i systemet, utan att behöva skriva om logik för andra delar.

Vi får även en applikation som är lättare att testa, eftersom man kan testa varje enhet för sig.

Ett exempel

Vi tänker oss ett scenario där vi har en entitet, en student.

Längst ner i vår applikation har vi ett datalager. Där vi sparar den faktiska datan, en rad per student. Detta kan vara i formen av SQL, JSON, XML etc. Det spelar i detta fallet ingen roll vilken teknik som står för lagringen.

Model
På detta har vi en Model. Vår modell representerar datan i objektsform och kan hämta ut det vi behöver från vår datalagring. Vår modell representerar en student, så vi kallar den för Student. Modellen vet ingenting om resten av vår applikation, utan bara hur man hämtar och sparar data.

Controller
Nästa del är vår Controller. Den vet ingenting om hur datan är sparad eller hur vår vy ser ut. Den har bara ett ansvarsområde, och det är att flytta information. Data från vår modell till vår vy, och händelser från vår vy till vår modell.

View
Det är detta som användaren ser. Det grafiska gränssnittet där datan från vår modell presenteras. Det är även här som användaren kan initiera händelser som ska vidare till vår modell. Ex. lägga till, uppdatera, radera en student. Alla dessa händelser skickas till vår Controller, som i sin tur säger till vår Model vad som behöver förändras. Hur det faktiskt sker är upp till modellen.

För att illustrera detta kan vi tänka oss att vi i vår applikation har en vy som visar en lista med studenter. Det är ursprungskravet från beställaren. Men, det tillkommer sen ett önskemål om att man ska kunna få en vy, där alla studenternas bilder visas istället.

Förutsatt att den datan finns lagrad och vår modell känner till den, så kan vi, utan att upprepa någon kod, enkelt lägga till en ny vy. Vi skapar vår vy, och berättar för vår kontroller att på '/bilder' så ska den hämta studenterna och skicka deras bilder till vår nya vy.

Att jobba i ett ramverk (Laravel)

Vi kommer att titta på hur vi arbetar med ramverket Laravel. Det släpptes i version 1 1 Juni 2011, och version 5, som är den vi kommer att jobba med, släpptes 4 Februari 2015.

Varför ska man jobba i ett ramverk?

Det är inte nödvändigt. Absolut inte. Ska man göra en väldigt enkel liten sak så finns det inget som hindrar en från att hoppa över ramverket. Det är nog snarare så att ett ramverk skulle lägga på en onödigt stor kodbas på ditt lilla projekt.

Men, så fort som projektet börjar växa lite så får man väldigt mycket gratis om man använder sig av färdiga komponenter och standarder. De flesta stora ramverk idag bygger på industristandarder, så följer du deras kodstil och rekommendationer så kan du vara säker på att din app också följer dessa.

Det som du egentligen får är färdigpaketerad 3:e-parts kod, som kan göra saker åt dig. Du slipper uppfinna användarhantering, formulärgenerering, hjulet igen. Något som kan vara en nackdel här är att man får förlita sig på att den som skrivit ramverket och paketen har gjort ett bra jobb. Men skulle man hitta defekter i det så går det bra att rätta dessa och ge tillbaka till skaparen och alla användare av paketet.

Modulerna är dessutom ofta skrivna så att de inte är knutna till just ditt ramverk, utan lär du dig att använda dem så kan du återanvända de paketen i nästa projekt, oavsett om du använder ett ramverk eller ej.

Det ger dig tid till att fokusera på vad din app ska göra, inte hur den ska göra det.

Det gör det även enklare för andra utvecklare att ta sig an ditt projekt. Antingen om du slutar jobba på det, eller om fler läggs till i ditt team. För strukturen ser ut på ett förutsägbart sätt, så en ny deltagare kan veta på ren instinkt och rutin var det är säkert att anta att en viss kod-del finns.

Du kan även läsa igenom koden i paketen och lära dig av hur de har löst ett visst problem.

Ordlista

• MVC - Model View Controller
• GUI - Graphical User Interface
• DRY - Don't Repeat Yourself