Model-View-Controller (MVC) Design Pattern

January 25  by Eliza

IOS rammer er objektorientert. En enkel måte å forstå hva det egentlig betyr er å tenke på et team som arbeider på et kontor. Arbeidet som må få gjort er delt opp og tildelt individuelle gruppemedlemmer (i dette tilfellet, gjenstander). Hvert teammedlem har en jobb og fungerer med andre gruppemedlemmer for å få ting gjort.

Hva mer er, gjør en god teammedlem bryr seg ikke hvordan andre medlemmer gjør sitt arbeid, bare at de gjør det i henhold til avtalt arbeidsdeling. Likeledes, et objekt i objektorientert programmering tar vare på sin egen virksomhet og bryr seg ikke hva objektet i den virtuelle bås naboen gjør, så lenge det vil gjøre det den er ment å gjøre da bedt om å gjøre det.

Objektorientert programmering ble opprinnelig utviklet for å gjøre koden mer vedlikeholdsvennlig, gjenbrukbare, utvidbar, og forståelig ved å innkapsle all funksjonaliteten bak veldefinerte grensesnitt. Den faktiske detaljer om hvordan noe fungerer (så vel som dets data) er skjult, noe som gjør endre og utvide et program mye enklere.

Stor - så langt - men et irriterende spørsmålet fortsatt plager programmerere:

Nøyaktig hvordan kan du bestemme på objektene og hva hver enkelt gjør?

Noen ganger er svaret på det spørsmålet er ganske enkelt - bare bruke den virkelige verden som en modell. I en roadtrip app, for eksempel, noen av klassene av modellobjektene er Trip, Events, Destination, og så videre. Men når det kommer til et generisk program struktur, hvordan kan du bestemme hva objektene skal være? Det kan ikke være så opplagt.

MVC mønsteret er en veletablert måte å gruppere programfunksjoner i gjenstander. Varianter av det har eksistert minst siden de tidlige dagene av Smalltalk, en av de aller første objektorienterte språk. MVC er et høyt nivå mønster - det løser arkitektur av en søknad og klassifiserer gjenstander i henhold til de generelle rollene de spiller i et program, snarere enn å bore ned i detaljer.

MVC mønsteret skaper, i praksis en miniatyr univers for programmet, befolket med tre forskjellige typer objekter. Den angir også roller og ansvar for alle tre typer objekter og spesifiserer hvordan de skal samhandle med hverandre. For å gjøre ting mer konkret (det vil si å holde hodet fra eksploderende), forestille seg en stor, vakker, 60-tommers flatskjerm-TV. Her er hovedpunkt:

  • Modellobjekter: Disse objektene sammen utgjør innholdet "motoren" i programmet ditt. De inneholder app data og logikk - noe som gjør din app mer enn bare et pent ansikt.

    Du kan tenke på modellen (som kan være ett objekt eller flere som samhandler) som en bestemt TV-program, en som, helt ærlig, ikke gir en ule om hva TV-apparatet det er vist på.

    Faktisk, bør modellen ikke gi en uling. Selv om den eier sine data, bør den ha noen forbindelse til brukergrensesnittet og bør være lykkelig uvitende om hva som er gjort med sine data.

  • Se objekter: Disse objektene vise ting på skjermen og svare på brukerhandlinger. Stort sett alt du kan se, er en form for visning objekt - vinduet og alle kontrollene, for eksempel.

    Dine synspunkter vet hvordan de skal vise informasjon de mottar fra modellen objekt og hvordan du kan få noen innspill fra brukeren modellen måtte trenge. Men selve visningen bør vite noe om modellen. Det kan håndtere en forespørsel om å vise noen hendelser, men det trenger ikke bry seg med hva som forespørsel betyr.

    Du kan tenke på visningen som en TV-skjerm som ikke bryr seg om hva program det er som viser eller hva kanalen du valgte.

    Den UIKit rammeverket gir mange ulike typer visninger, som du finne ut i neste avsnitt.

    Hvis utsikten vet ingenting om modellen, og modellen vet ingenting om utsikten, hvordan får du data og andre varsler å passere fra den ene til den andre? For å få den samtalen i gang (Modell: "Jeg har nettopp oppdatert mine data." Se: "Hei, gi meg noe å vise," for eksempel), må du den tredje elementet i MVC triumviratet, kontrolleren.

  • Controller objekter: Disse objektene koble vise objekter programmets til sine modellobjektene. De leverer de vise objekter med det de trenger for å vise (får det fra modellen) og også gi modellen med brukerundersøkelser fra visningen.

    Du kan tenke på kontrolleren som den krets som trekker showet ut av kabel og deretter sender den til skjermen eller ber om en bestemt pay-per-view-show.

Den grunnleggende program arkitektur ser ut som figur 4-8.

Model-View-Controller (MVC) Design Pattern


Når du tenker på din søknad i form av kontroller objekter, utsikt modell, og begynner UIKit rammeverk for å gi mening. Forstå rammene denne måten begynner også å løfte tåke hengende over hvor du skal gjøre minst en del av det programspesifikke oppførsel gå.

Før du går inn som tema, men trenger du å vite litt mer om klassene at UIKit gir, fordi disse er de gutta vil du oppgaven med å implementere MVC design mønster - vindus klasser, vise klasser, og utsikt kontrolleren klasser.

I Objective-C, klasser inkluderer instansvariabler, egenskaper og metoder (som kan få tilgang instansvariabelene av en klasse). Klassene er om filer i prosjektet som inneholder kode. Klassene er typer i ditt program.

Gjenstander, på den annen side, finnes under kjøring, og også eksempler på en klasse. Du kan tenke på en klasse som en blåkopi å bygge et objekt av denne typen.