Mål
Laboration 3 syftar till att ge dig en en introduktion till en programvaruarkitekturen
Studenten skall efter avslutat laboration…
- …läst och förstått en mjukvaruarkitektur
- …omarbetat koden för att passa MVC arkitektur
- …testat kravuppfyllelse med testfall
- …mätt kodkvalitet med hjälp utav code-review
Teori
MVC, Model View Controller
MVC är en mjukvaruarkitektur. En MVC-arkitektur hjälper programmeraren att dela upp kodens ansvar i olika komponenter.
Det finns tre grundläggande komponenter de är:
Model
Model ansvarar för den affärslogik som programmet innehåller. I inloggningsexemplet har vi tex regler kring hur och vem som kan logga in. Komponenten Model håller vi helt fri från presentationsspecifika delar. Det betyder att i Model finns ingen HTML, CSS, länkar eller bilder. Klasser i modellen har inte heller någon kännedom om vare sig klasser i Controller eller View.
Exempel på namn på Modelklasser och ansvarsområden från min lösning av laborationen.
- LoginModel sköter regler för inloggning, utloggning, man kan även fråga den om en användare redan är inloggad.
- LoginObserver, Interface för call-backs vid inloggning
- TemporaryPassword, abstrakt klass som håller ett lösenord
- TemporaryPasswordClient, innehåller temporära lösenord som exempelvis kan lagras hos en klient.
- TemporaryPasswordServer, innehåller regler för hur man matchar ett temporärt lösenord hos en klient med kopian på servern. Har även regler för hur länge ett temporärt lösenord får gälla och kan lagra av temporära lösenord som strängar
- UserCredentials, innehåller regler för vad som är giltiga användaruppgifter och lösenord.
- UserList, innehåller regler för vilka användare som finns lagrade i systemet, innehåller regler för om man kan spara en ny användare eller inte och om en viss användare finns.
View
View ansvarar för att tillhandahålla ett gränssnitt mot användaren. Detta gränssnitt realiserad tex med hjälp utav HTML och CSS men även i stor del protokollet som används för att kommunicera med användaren HTTP. Så skriver du en rad HTML så ska den ligga i View.
Till skillnad mot en del MVC ramverk så skiljer sig kursens version av MVC genom att låta view också ansvara för att ta emot och tolka indata. Detta gör vi för att minska beroenden och låter view bli ett gränssnitt som hanterar hela kommunikationen med användaren.
Exempel på namn Viewklasser och ansvarsområden från min lösning av laborationen:
- LoginView, ansvarar för att skapa HTML för login-formuläret, “Logga ut” länken och meddelanden vid inloggning. Hämtar indata från rätt plats i $_GET,$_POST och $_COOKIE. Implementerar interfacet LoginObserver.
- ApplicationView, ansvarar för att generera utdata(HTML) för hela applikationen, kombinerar HTML från exempelvis LoginView med HTML för applikationen, skapar HTML för länkar, hanterar indata i $_GET för att avgöra vilken sida som är aktiv.
Controller
Controller ansvarar för att inkapsla flöden och jag likställer ibland Controller med use-cases. En controller inkapslar det logiska flödet av kommunikation mellan användaren och systemet precis som ett Use-case.
Exempel på namn Controller-klasser och ansvarsområden från min lösning av laborationen:
- LoginController, ansvarar för användarfallen UC1, UC2, UC3, Hämtar indata från LoginView och anropar rätt metoder i Model för att Logga in och ut.
- Application, ansvarar för navigering mellan olika use-cases, ansvarar även för vilka use-cases som är aktiva beroende på om man är inloggad eller inte.
Beroenden
MVC begränsar hur man får skapa beroenden mellan klasser.
- Inga beroenden från en klass i Model till Controller
- Inga beroenden från en klass i Model till View
- Inga beroenden från en klass i View till Controller
När det gäller beroenden finns det flera typer.
- Explicita beroenden, är sådana som syns i klassdiagram, Vi skapar en instans av den andra klassen, tar emot som argument i en funktion eller liknande.
- Implicita beroenden, är inte lika lätta att se och därmed värre än ett explicit beroende. Exempel på implicita beroenden är beroenden genom global variabel, strängberoenden (ex. En sträng i HTML till en plats i $_GET). Eller ett kolumnnamn i en databas används från två olika klasser.
Som ni förstår är Implicita beroenden värre att upptäcka, hantera och underhålla.
Beteenden
Vår version av MVC begränsar även hur du får placera beteende i dina klasser.
Reglerna för detta är följande:
- Model inkapslar regler och data
- View är det enda stället där du skriver HTML, CSS eller hanterar bilder och länkar.
- View är enda stället där du använder följande superglobala arrayer $_GET, $_POST, $_FILES, $_COOKIE, $_REQUEST. Strängar och meddelanden som syns är också en del av View.
Sedan har jag ett gäng med rekommendationer
- View är det stället där du normalt sett filtrerar indata, filtreringen kan dock ske genom regler från Model.
- Controller känner inte till hur View kommunicerar, exempelvis att det finns knappar eller länkar utan är mer som ett användningsfall
Uppgift 1. Identifiera och lös brott mot MVC
Din uppgift är nu att hitta brott mot “vår” MVC-arkitektur i följande kod. https://github.com/dntoll/1DV408NOTMVCHT2013
Det finns 9 brott mot MVC kan du hitta alla?
Ladda ner och rätta de brotten du hittar.
Uppgift 2. Omarbeta koden från laboration 1&2 till MVC
Du kommer nu behöva skriva om din kod för att passa MVC arkitektur. Om du inte skrivit din applikation som MVC är det inte säkert att du kan behålla mycket av den kod du skrivit tidigare. Gör därför en Commit för att se till att din kod finns i versionshanteringen.
Skapa katalogstruktur med separata kataloger för Model, View och Controller.
I dessa lägger du dina nya klasser så att det tydligt syns att en viss klass är del av M, V eller C.
MVC-testet
För att bedöma brott mot MVC letar du brott mot följande regler. Vad som räknas som beroende eller beteende är specificerat under Teori.
- Alla Model-klasser ligger i katalogen Model
- Alla View-klasser ligger i katalogen View
- Alla Controller-klasser ligger i katalogen Controller
- Inga beroenden från Model till Controller
- Inga beroenden från Model till View
- Inga beroenden från View till Controller
- Inget beteende i Model som borde ligga i Controller
- Inget beteende i Model som borde ligga i View
- Inget beteende i Controller som borde ligga i Model
- Inget beteende i Controller som borde ligga i View
- Inget beteende i View som borde ligga i Controller
- Inget beteende i View som borde ligga i Model
Testning
Svara på enkäten
För att kunna svara på denna uppgift måste du vara inloggad.
Code-review
Svara på enkäten
För att kunna svara på denna uppgift måste du vara inloggad.
Skicka in kod
Ladda upp din kod
För att kunna svara på denna uppgift måste du vara inloggad.
Bedömningsmodell
För godkänd:
- Du skall uppfylla 100% av testfallen
- Kodkvalitet skall vara hög
- Dina klasser skall passera MVC testet
- Ingen kod får vara kopierad från andra eller taget från nätet
Glöm inte bort att laboration 3.2 finns!
