Share
Model-View-Controller (MVC) er trolig et av de mest siterte mønstrene i webprogrammeringsverdenen de siste årene. Alle som jobber med noe som er relatert til webapplikasjonsutvikling, vil ha hørt eller lest akronymet hundrevis av ganger. I dag vil vi avklare hva MVC betyr, og hvorfor det har blitt så populært.
MVC er ikke et designmønster, det er et arkitektonisk mønster som beskriver en måte å strukturere vår søknad på og ansvar og samspill for hver del i den strukturen.
Det ble først beskrevet i 1979, og selvfølgelig var konteksten litt annerledes. Begrepet webapplikasjon eksisterte ikke. Tim Berners Lee sådde frøene fra World Wide Web tidlig på nittitallet og forandret verden for alltid. Mønsteret vi bruker i dag for webutvikling er en tilpasning av det opprinnelige mønsteret.
Den vanlige popularisering av denne strukturen for webapplikasjoner skyldes at den er innlemmet i to utviklingsrammer som har blitt enormt populære: Struts og Ruby on Rails. Disse to miljøene markerte veien for de hundrevis av rammeverk som ble opprettet senere.
Ideen bak arkitekturmønsteret Model-View-Controller er enkelt: Vi må ha følgende ansvar klart skilt i vår søknad:
Søknaden er delt inn i disse tre hovedkomponentene, hver med ansvar for ulike oppgaver. La oss se en detaljert forklaring og et eksempel.
De Controller administrerer brukerforespørsler (mottatt som HTTP GET eller POST-forespørsler når brukeren klikker på GUI-elementer for å utføre handlinger). Hovedfunksjonen er å ringe og samordne de nødvendige ressursene / objektene som trengs for å utføre brukerens handling. Kontrolleren vil vanligvis ringe til riktig modell for oppgaven og deretter velge riktig visning.
De Modell er dataene og reglene som gjelder for dataene, som representerer begreper som applikasjonen håndterer. I et hvilket som helst programvaresystem er alt modellert som data vi håndterer på en bestemt måte. Hva er en bruker, en melding eller en bok for et program? Bare data som må håndteres i henhold til bestemte regler (dato kan ikke være i fremtiden, e-post må ha et bestemt format, navn kan ikke være mer enn x tegn langt osv.).
Modellen gir kontrolleren en datarrepresentasjon av hva brukeren ba om (en melding, en liste over bøker, et fotoalbum, osv.). Denne datamodellen vil være den samme uansett hvordan vi kanskje vil presentere den til brukeren, derfor kan vi velge hvilken som helst tilgjengelig visning for å gjøre det.
Modellen inneholder den viktigste delen av søknadslogikken, logikken som gjelder det problemet vi har å gjøre med (et forum, en butikk, en bank, etc.). Kontrolleren inneholder en mer intern organisatorisk logikk for selve applikasjonen (mer som housekeeping).
De Utsikt gir forskjellige måter å presentere data mottatt fra modellen. De kan være maler der dataene er fylt. Det kan være flere forskjellige visninger, og kontrolleren må bestemme hvilken som skal brukes.
En webapplikasjon består vanligvis av et sett av kontroller, modeller og visninger. Kontrolleren kan være strukturert som en hovedkontroller som mottar alle forespørsler og kaller bestemte kontrollører som håndterer handlinger for hvert tilfelle.
Anta at vi utvikler en online bokhandel. Brukeren kan utføre handlinger som: vise bøker, registrere, kjøpe, legge til elementer i gjeldende rekkefølge, opprette eller slette bøker (hvis han er administrator osv.). La oss se hva som skjer når brukeren klikker på fantasi kategori for å vise titlene vi har tilgjengelig.
Vi vil ha en bestemt kontroller til å håndtere alle bøkerrelaterte handlinger (se, redigere, lage, osv.). La oss kalle det books_controller.php for dette eksemplet. Vi vil også ha en modell, for eksempel book_model.php, håndtering av data og logikk relatert til varene i butikken. Til slutt vil vi ha en rekke synspunkter for å presentere for eksempel en liste over bøker, en side for å redigere bøker, osv.
Følgende figur viser hvordan brukerens forespørsel om å vise fantaseboklisten håndteres:
Kontrolleren (books_controller.php) mottar brukerforespørselen [1] som en HTTP GET eller POST-forespørsel (vi kan også ha en sentral kontroller, for eksempel index.php motta den og deretter ringe books_controller.php).
Kontrolleren undersøker forespørselen og parametrene og kaller modellen (book_model.php) spør Han skal returnere listen over tilgjengelige fantasybøker [2].
Modellen er ansvarlig for å få den informasjonen fra databasen (eller hvor den er lagret) [3], bruk filtre eller logikk om nødvendig, og returner dataene som representerer listen over bøker [4].
Kontrolleren vil bruke riktig visning [5] for å presentere disse dataene til brukeren [6-7]. Hvis forespørselen kom fra en mobiltelefon, vil en visning for mobiltelefoner bli brukt, hvis brukeren har valgt en bestemt hud, vil tilsvarende visning bli valgt, og så videre.
Den mest åpenbare fordelen vi får ved å bruke MVC, er en klar adskillelse av presentasjon (grensesnittet med brukeren) og applikasjonslogikk.
Støtte for ulike typer brukere som bruker ulike typer enheter, er et vanlig problem i disse dager. Grensesnittet som presenteres, må være annerledes hvis forespørselen kom fra en stasjonær datamaskin eller fra en mobiltelefon. Modellen returnerer nøyaktig samme data, den eneste forskjellen er at kontrolleren vil velge en annen visning for å gjøre dem (vi kan tenke på en annen mal).
Bortsett fra å isolere utsikten fra forretningslogikken, reduserer M-V-C-separasjonen kompleksiteten ved utforming av store applikasjoner. Koden er mye mer strukturert og derfor lettere å vedlikeholde, teste og gjenbruke.
Når du bruker et rammeverk, er grunnstrukturen for MVC allerede forberedt, og du må bare utvide den strukturen og plassere filene i riktig katalog for å overholde modell-View-Controller-mønsteret. Også du får mye funksjonalitet allerede skrevet og grundig testet.
Ta kakePHP som et eksempel MVC rammeverk. Når du har installert det, ser du tre hovedkataloger:
De app mappen er hvor du plasserer filene dine. Det er ditt sted å utvikle din del av søknaden.
De kake mappe er hvor cakePHP har sine filer og hvor de har utviklet sin rolle (hovedrammefunksjonalitet).
De leverandører mappen er for tredjeparts PHP biblioteker hvis det er nødvendig.
Arbeidsstedet ditt (appkatalog) har følgende struktur:
Nå må du sette dine kontrollører i kontrollere katalog, modellene dine i modeller katalog og visninger i ... the visninger katalog!
Når du er vant til rammen din, kan du vite hvor du skal lete etter nesten alle deler av koden du må endre eller opprette. Denne organisasjonen alene gjør vedlikeholdet enklere.
Siden denne veiledningen ikke er ment å vise deg hvordan du oppretter et program ved hjelp av cakePHP, bruker vi det bare for å vise eksempelkoden for modell-, visnings- og kontrollerkomponenter og kommentere fordelene ved å bruke et MVC-rammeverk. Koden er forenklet og ikke egnet for ekte applikasjoner.
Husk at vi hadde en bokhandel og en nysgjerrig bruker som ønsker å se hele listen over bøker i fantasi kategori. Vi sa at kontrolleren vil være den som mottar forespørselen og koordinerer de nødvendige tiltakene.
Så når brukeren klikker, vil nettleseren be om denne nettadressen:
www.ourstore.com/books/list/fantasy
CakePHP liker å formatere nettadresser i skjemaet / controller / action / param1 / param2, hvor handling er funksjonen å ringe i kontrolleren. I det gamle klassiske urlformatet ville det være:
www.ourstore.com/books_controller.php?action=list&category=fantasy
Ved hjelp av cakePHP-rammeverk, ser vår kontroller ut slik:
Accentsconagua
sett ('bøker', $ this-> Book-> findAllByCategory ($ kategori)); funksjon legge til () ... funksjon slette () ... ...?> Enkelt, er det ikke ?. Denne kontrolleren vil bli lagret som books_controller.php og plassert i / app / controllers. Den inneholder listefunksjonen, for å utføre handlingen i vårt eksempel, men også andre funksjoner for å utføre andre bokrelaterte handlinger (legge til en ny bok, slette en ny bok osv.).
Rammen gir mange ting for oss, og bare en linje er nødvendig for å liste bøkene. Vi har grunnklasser med grunnleggende kontrolleradministrasjon som allerede er definert, så vi arver fra dem (AppController som arver fra Controller).
Alt du trenger å gjøre i listen handlingen er å ringe modellen for å få dataene og deretter velge en visning for å presentere den til brukeren. La oss forklare hvordan dette er gjort.
dette-> Bestill er vår modell, og denne delen:
$ Dette-> Book-> findAllByCategory ($ kategori)
forteller modellen å returnere listen over bøker i den valgte kategorien (vi ser modellen senere).
De sett metode i linjen:
$ this-> set ('books', $ this-> Book-> findAllByCategory ($ category)); Er kontrolleren måte å sende data til visningen. Det setter bøker variabel til dataene returnert av modellen og gjør den tilgjengelig for visningen.
Nå må vi bare gjøre visningen, men dette vil bli gjort automatisk av cakePHP hvis vi vil ha standardvisningen. Hvis vi trenger en annen visning, må vi bare kalle det eksplisitt ved hjelp av gjengi metode.
Modellen er enda enklere:
Hvorfor tom? Fordi den arver fra en grunnklasse som gir nødvendig funksjonalitet, og vi har fulgt CakePHP-navnkonvensjonene for å tillate rammen til å utføre andre oppgaver automatisk. For eksempel kjenner cakePHP, basert på navn, at denne modellen brukes i BooksController, og at den vil få tilgang til en databasetabell som heter bøker.
Med denne erklæringen har vi bare en bokmodell som er i stand til å lese, slette eller lagre data fra databasen
Koden vil bli lagret som book.php og plassert i / app / modeller.
Alt vi trenger å gjøre nå, er å opprette en visning (minst en) for listespillet. Visningen vil ha HTML-koden og noen få (så få som mulige) PHP-linjer å sløyfe gjennom bøkerarmen som tilbys av modellen.
| Tittel | Forfatter | Pris |
|---|---|---|
Som vi kan se, produserer ikke visningen en komplett side, bare et HTML-fragment (et bord i dette tilfellet). Dette skyldes at CakePHP gir en annen måte å definere layouten på siden, og visningene settes inn i det aktuelle layoutet. Rammeverket gir oss også noen hjelpeposter for å gjøre felles oppgave enkel når du lager disse HTML-utdragene (sett inn skjemaer, koblinger, Ajax eller JavaScript).
Vi gjør dette til standardvisning ved å lagre det som list.ctp (listen er navnet på handlingen og ctp betyr kakemalen) og plasserer den i / app / visninger / bøker (inne i bøker fordi disse er visninger for bøkerstyringshandlinger).
Og dette fullfører de tre komponentene ved hjelp av CakePHP-rammeverket!
Vi har lært hva som trolig er det mest brukte arkitektoniske mønsteret i dag. Vi må være klar over at når vi snakker om mønstre i programmeringsverdenen, snakker vi om fleksible rammer, som skal skreddersys for det aktuelle problemet ved hånden. Vi finner implementeringer som introduserer variasjoner i strukturen vi har sett, men det viktigste er at til slutt hjelper mønsteret oss til å oppnå en klar oppdeling mellom ansvar og bedre vedlikehold, kodeutnyttelse og testing.
Vi har også sett fordelene ved å bruke et MVC-rammeverk som gir oss et grunnleggende MVC-skjelett og mye funksjonalitet, forbedrer produktiviteten og gjør utviklingsprosessen enklere. Takk for at du leste!
