MVC-designmønstre fra bunnen av. MVC-prinsippet i webprogrammering

Design mønster Model-View-Controller (MVC) er et programvarearkitekturmønster bygget rundt å holde representasjonen av data atskilt fra metodene som samhandler med dataene.

Selv om MVC opprinnelig ble utviklet for personlige datamaskiner, har den blitt tilpasset og mye brukt av webutviklere på grunn av dens nøyaktige separasjon av bekymringer og muligheten til å gjenbruke kode. Ordningen oppmuntrer til utvikling av modulære systemer, som lar utviklere raskt oppdatere, legge til eller fjerne funksjonalitet.

I denne artikkelen vil jeg beskrive de grunnleggende prinsippene, samt se på definisjonen av en konstruksjonsordning og et enkelt MVC PHP eksempel.

Hva er MVC

Navnet på et designmønster bestemmes av dets tre hovedkomponenter: Model, View og Controller. Den visuelle representasjonen av MVC-mønsteret ser ut som vist i diagrammet nedenfor:

Figuren viser strukturen til en enveis dataflyt og dens veier mellom ulike komponenter, samt deres interaksjon.

Modell

En modell er et permanent depot av data som brukes gjennom en struktur. Den skal gi tilgang til data for visning, valg eller opptak. I den overordnede strukturen er "Modellen" broen mellom "View" og "Controller"-komponentene.

"Modellen" har imidlertid ingen forbindelse eller informasjon om hva som skjer med dataene når de sendes til "View"- eller "Controller"-komponentene. Den eneste oppgaven til "Modellen" er å behandle data i vedvarende lagring, søke og klargjøre data overført til andre komponenter i MVC.

"Modellen" skal fungere som en "gatekeeper", stå i nærheten av datavarehuset og ikke stille spørsmål, men akseptere alle innkommende forespørsler. Dette er ofte den mest komplekse delen av et MVC-system. "Modell" -komponenten er toppen av hele strukturen, siden uten den er forbindelsen mellom "Controller" og "View" umulig.

Opptreden

Visningen er den delen av systemet der dataene som forespørres fra modellen får den endelige formen for utdata. I webapplikasjoner bygget på MVC er "View" komponenten der HTML-koden genereres og vises.

Visningen avskjærer også brukerens handling, som deretter sendes til "Kontrolleren". Et typisk eksempel på dette er knappen som genereres av "Vis". Når brukeren klikker på det, utløses en handling i "Kontrolleren".

Det er flere vanlige misoppfatninger om View-komponenten. For eksempel tror mange feilaktig at "View" ikke har noen forbindelse med "Modellen", og alle viste data overføres fra "Controller". I virkeligheten tar ikke dette dataflytdiagrammet hensyn til teorien bak MVC-arkitektur. I sin artikkel beskriver Fabio Cevasco denne ukorrekte tilnærmingen ved å bruke eksemplet på et av de ikke-tradisjonelle MVC PHP-rammeverkene:

"For å bruke MVC-arkitekturen riktig, bør det ikke være noen interaksjon mellom modellen og visningen: all logikk håndteres av kontrolleren."

I tillegg er definisjonen av "View" som en malfil også unøyaktig. Men dette er ikke en persons feil, men resultatet av mange feil fra forskjellige utviklere, som fører til en generell misforståelse. Da forklarer de det feil for andre. Faktisk er "View" mye mer enn bare en mal. Men moderne MVC-orienterte rammeverk har absorbert denne tilnærmingen i en slik grad at ingen lenger bryr seg om den riktige MVC-strukturen støttes eller ikke.

View-komponenten sendes aldri data direkte av kontrolløren. Det er ingen direkte forbindelse mellom "View" og "Controller" - de er koblet til ved hjelp av "Modellen".

Kontroller

Dens oppgave er å behandle dataene som brukeren legger inn og oppdatere "Modellen". Dette er den eneste delen av diagrammet som krever brukerinteraksjon.

"Kontroller" kan defineres som en innsamler av informasjon, som deretter overføres til "Modellen" og deretter organiseres for lagring. Den inneholder ingen annen logikk enn behovet for å samle inn innkommende data. "Kontrolleren" kobles også til bare en "View" og en "Model". Dette skaper et enveis dataflytsystem med én inngang og én utgang ved kommunikasjonspunktene.

Kontrolleren mottar oppgaver som skal utføres kun når brukeren samhandler med visningen, og hver funksjon avhenger av brukerens interaksjon med visningen. Den vanligste feilen utviklere gjør er at de forveksler kontrolleren med gatewayen, så de tildeler den funksjoner og oppgaver som hører til visningen.

En annen vanlig feil er å gi "kontrolleren" funksjoner som kun er ansvarlige for å behandle og overføre data fra "modellen" til "visningen". Men i henhold til strukturen til MVC-mønsteret, bør denne interaksjonen utføres mellom "Model" og "View".

MVC i PHP

La oss skrive en nettapplikasjon i PHP, hvis arkitektur er basert på MVC. La oss starte med et eksempel på wireframe:

string = "MVC + PHP = Fantastisk!"; ) )kontroller = $kontroller; $this->model = $modell; ) offentlig funksjon output() ( return "

" . $this->modell->streng ."

"; } } modell = $modell; ) )

Vi har et prosjekt med flere hovedklasser for hver maldel. Nå må du konfigurere forholdet mellom dem:

produksjon();

I PHP MVC-eksemplet ovenfor er det ingen spesifikk funksjonalitet for kontrolleren fordi applikasjonen ikke definerer brukerinteraksjoner. Visningen inneholder all funksjonalitet, siden vårt eksempel kun er ment for demonstrasjonsformål.

La oss utvide eksemplet for å vise hvordan vi vil legge til kontrollerfunksjonalitet, og dermed legge til interaksjon til applikasjonen:

string = "MVC + PHP = Fantastisk, klikk her!"; ) )kontroller = $kontroller; $this->model = $modell; ) offentlig funksjon output() ( return "

modell->streng . "

"; } } modell = $modell; ) public function clicked() ( $this->model->string = "Oppdaterte data, takket være MVC og PHP!"; ) )

Vi har utvidet programmet med grunnleggende funksjonalitet. Å sette opp interaksjoner mellom komponenter ser nå slik ut:

($_GET["handling"])(); ) echo $view->output();

Mønster Model-View-Controller (MVC), oppdaget på slutten av 1970-tallet, er et designmønster for programvarearkitektur hvis hovedmål er å skille datafunksjoner fra datapresentasjon. Teoretisk sett vil en godt designet MVC-applikasjon tillate front-end- og back-end-utviklere å ikke forstyrre hverandres ansvarsområder under arbeidet, det vil si at front-end-utvikleren ikke trenger å vite noe om "kjøkkenet" av sin back-end kollega og omvendt.

Selv om MVC opprinnelig ble designet for desktop-applikasjonsutvikling, har den blitt tilpasset moderne oppgaver og er ekstremt populær blant webutviklere fordi den gjør det mulig å lage renere, mer gjenbrukbar kode ved å skille ansvar. MVC-mønsteret resulterer i rene, modulære systemer som lar utviklere gjøre endringer i eksisterende kode veldig raskt.

I denne artikkelen skal vi se på de grunnleggende prinsippene for MVC, starter med definisjonen av et mønster og fortsetter med dets anvendelse i et lite eksempel. Denne artikkelen vil først og fremst være nyttig for de som aldri har møtt dette mønsteret i livet, og kanskje også for de som ønsker å friske opp kunnskapen om MVC.

Forstå MVC

Som allerede nevnt kommer navnet på mønsteret fra en forkortelse av tre ord: Modell (modell), Utsikt Og Kontroller. Kort fortalt kan mønsterets virkemåte illustreres med ett diagram (finnes på Wikipedia):

Dette diagrammet viser tydelig den ensrettede informasjonsflyten i mønsteret og beskriver også rollene til hver komponent.

Modell

Modellen brukes til å få tilgang til og manipulere data. I de fleste tilfeller er modellen det som brukes for å få tilgang til datalageret (for eksempel en database). Modellen gir et grensesnitt for å søke i data, lage dem, endre dem og slette dem fra lagring. I sammenheng med MVC-mønsteret er modellen formidleren mellom utsikten og kontrolleren.

En ekstremt viktig egenskap ved en modell er at den teknisk sett ikke har kunnskap om hva som skjer med dataene i kontrolleren og visningen. Modellen skal aldri sende eller vente på forespørsler til/fra andre mønsterkomponenter.

Husk imidlertid alltid at modellen ikke bare er en inngangsport til en database eller et annet system som ikke gjør annet enn å overføre data frem og tilbake. En modell er som en inngangsport til dataene. Modellen er i de fleste tilfeller den mest komplekse delen av systemet, blant annet på grunn av at modellen i seg selv er bindeleddet for alle andre deler.

Opptreden

Visningen er der dataene mottatt fra modellen vises i ønsket form. I tradisjonelle nettapplikasjoner utviklet ved hjelp av MVC-mønsteret, er visningen den delen av systemet hvor HTML-koden genereres. Visningen er også ansvarlig for å motta handlinger fra brukeren for å sende dem til kontrolløren. En visning gjengir for eksempel en knapp i brukergrensesnittet og, når den klikkes, påkaller den tilsvarende kontrollerhandlingen.

Det er noen misoppfatninger om formålet med en visning, spesielt blant nettutviklere som akkurat har begynt å bygge applikasjonene sine ved hjelp av MVC. En av de mest brutte reglene er det utsikten skal ikke kommunisere med modellen på noen måte, og alt dataene som visningen mottar, skal kun komme fra behandlingsansvarlig. I praksis ignorerer utviklere ofte dette konseptet, som er kjernen i MVC-mønsteret. Fabio Cevascos artikkel illustrerer denne forvirrende tilnærmingen til MVC ved å bruke CakePHP, en av mange ikke-standard MVC-rammeverk:

Det er ekstremt viktig å forstå at for å få en skikkelig MVC-arkitektur, bør det ikke være noen direkte interaksjoner mellom visninger og modeller. All logikk for utveksling av data mellom dem må implementeres i kontrollere.

I tillegg er det en vanlig misforståelse at en visning bare er en malfil. Som Tom Butler bemerket, er denne misforståelsen enorm på grunn av det faktum at mange utviklere misforstår MVC-strukturen helt fra begynnelsen, hvoretter de begynner å helle denne "kunnskapen" videre inn i massene av nybegynnere. I virkeligheten er en visning mye mer enn bare en mal, men mange rammeverk bygget på toppen av MVC-mønsteret har forvrengt konseptet med en visning så mye at ingen bryr seg om applikasjonene deres er korrekte i forhold til MVC-mønsteret.

Et annet viktig poeng er at visningen aldri fungerer med "rene" data fra kontrolleren, det vil si at kontrolleren aldri jobber med visningen uten å omgå modellen. Under samspillet mellom kontrolleren og visningen, bør modellen alltid være mellom dem.

Kontroller

Kontrolleren er den siste delen av MVC-pakken. Kontrollørens jobb er å motta data fra brukeren og manipulere modellen. Det er kontrolleren, og bare den, som er den delen av systemet som samhandler med brukeren.

I et nøtteskall kan en kontroller beskrives som en informasjonsinnsamler som sender den videre til modellen for prosessering og lagring. Den skal ikke gjøre noe med dataene, men kun kunne motta den fra brukeren. Kontrolleren er assosiert med én visning og én modell, og organiserer dermed en ensrettet dataflyt som kontrollerer den på hvert trinn.

Det er veldig viktig å huske at kontrolleren bare starter sitt arbeid som et resultat av brukerinteraksjon med visningen, som kaller den tilsvarende kontrollerfunksjonen. Den vanligste feilen blant utviklere er å se kontrolleren som ganske enkelt en gateway mellom visningen og modellen. Som et resultat er kontrolleren utstyrt med de funksjonene som bør utføres av visningen (forresten, det er her ideen om at en visning bare er en malfil kommer fra). På toppen av det er det mange som fullstendig dumper all databehandlingslogikken, og glemmer hva modellen er ment for i MVC-mønsteret.

MVC i PHP

Jeg foreslår at du prøver å implementere det ovennevnte i en liten applikasjon. La oss starte med å lage modell-, visnings- og kontrollerklassene:

string = "MVC + PHP = Fantastisk!"; ) )kontroller = $kontroller; $this->

" . $this->modell->streng ."

"; } } modell = $modell; ) )

Hovedklassene er klare. La oss nå koble dem sammen og kjøre applikasjonen vår:

produksjon();

Som du kan se, har kontrolleren ingen funksjonalitet siden brukeren ikke samhandler med applikasjonen på noen måte. All funksjonalitet er plassert i visningen, siden vår applikasjon kun er beregnet på å vise data.

La oss utvide applikasjonen litt ved å legge til litt interaktivitet for å se hvordan kontrolleren fungerer:

string = "MVC + PHP = Fantastisk, klikk her!"; ) )kontroller = $kontroller; $this->model = $modell; ) offentlig funksjon output() ( return "

modell->streng . "

"; } } modell = $modell; ) public function clicked() ( $this->model->string = "Oppdaterte data, takket være MVC og PHP!") )

Og til slutt, la oss modernisere tilkoblingskoden litt:

($_GET["handling"])(); ) echo $view->output();

Resultater

I denne korte artikkelen så vi på de grunnleggende konseptene til MVC-designmønsteret og utviklet en enkel applikasjon basert på det, selv om vi selvfølgelig fortsatt er et stykke unna å bruke det i det virkelige liv. I den neste artikkelen vil vi se på hovedvanskene du vil møte hvis du blir mer involvert i å bygge en applikasjonsarkitektur basert på MVC-mønsteret. Følg med!

MVC-prinsippet webprogrammering (Model - View - Controller, Model - View (View) - Controller) er en av de mest vellykkede ideene i dag. MVC-prinsippet intuitivt ved første øyekast, men ikke veldig enkelt når det fordypes. La oss først se på hva den er ment for.

MVC-prinsippet, lar deg skille implementeringen av applikasjonslogikk, utseende (grafisk grensesnitt, GUI) og brukerinteraksjon.

Dette resulterer i mer strukturert kode, lar mer spesialiserte personer jobbe med prosjektet, gjør koden enklere å vedlikeholde og gjør den mer logisk og forståelig. En endring i en komponent har minimal innvirkning på de andre. Du kan koble forskjellige typer og forskjellige kontrollere til én modell.

På den annen side krever dette større ytelse av utførelsesmaskiner, men i det siste har ikke dette vært et stort problem – stadig mer komplekse programmeringsløsninger krever støtte, og støttekostnadene vil langt overstige kostnadene til kraftigere moderne utstyr.

MVC-prinsippet Nesten alle moderne rammeverk bruker det.

La oss se nærmere på komponentene.

Modell(Modell) - inneholder den såkalte "forretningslogikk" - behandling og verifisering av data, tilgang til databaser, representerer den interne strukturen til systemet. Modellen skal ikke samhandle direkte med brukeren.

Utsikt(Vis, Vis) beskriver utseendet til applikasjonen.

Kontroller- forbindelsesleddet mellom modellen og visningen, mottar data fra brukeren, overfører det til modellen, mottar det behandlede resultatet og overfører det til visningen.

Forholdet kan sees i diagrammet:

Bildekilde: http://www.wikipedia.org Komponentkrav:

Modeller:

må inneholde egenskaper som representerer spesifikke data;
må inkludere forretningslogikk (for eksempel valideringsregler) for å sikre at dataene oppfyller kravene;
kan inneholde kode for arbeid med data.

Representasjon:

bør primært inneholde markeringer som HTML og enkel PHP-kode som brukes til å krysse, formatere og vise data;
skal ikke ha direkte tilgang til databasen. Dette er hva modeller bør gjøre;
skal ikke ha direkte tilgang til $_GET , $_POST og andre variabler hentet fra brukerforespørselen. Denne oppgaven må utføres av kontrolløren. Visninger skal kun brukes til å formatere dataene mottatt fra kontrolleren og modellen;
kan få direkte tilgang til egenskaper og metoder for kontrolleren eller modellene. Dette bør imidlertid bare gjøres for datavisningsformål.

Kontrollere:

kan få tilgang til $_GET , $_POST og andre PHP-variabler hentet fra brukerforespørselen;
kan opprette og administrere modellforekomster. For eksempel, i en typisk modelloppdateringshandling, kan kontrolleren først opprette en forekomst av modellen, deretter fylle den med data fra $_POST og, hvis modellen er vellykket lagret, omdirigere brukerens nettleser til siden til den opprettede modellen. Det er verdt å merke seg at lagring av selve modellen bør implementeres i modellklassen, ikke i kontrolleren;
må ikke inneholde SQL-spørringer. Det er bedre å holde dem i modeller;
må ikke inneholde HTML eller annen markering. Det er verdt å sette det inn i presentasjonen.

(Krav hentet herfra: http://yiiframework.ru/doc/guide/ru/basics.best-practices)

Foruten MVC-konseptet er det mange andre, for eksempel BEVEGE SEG ( M odeler, O perasjoner, V iews og E ventiler) - litt som evolusjon MVC(hentet herfra: http://habrahabr.ru/post/147038/), men disse konseptene er mindre vanlige.

God ettermiddag, kjære kolleger. I denne artikkelen vil jeg gjerne snakke om min analytiske forståelse av forskjellene mellom MVC-, MVP- og MVVM-mønstrene. Jeg ble bedt om å skrive denne artikkelen av ønsket om å forstå moderne tilnærminger til utvikling av stor programvare og de tilsvarende arkitektoniske funksjonene. På det nåværende stadiet av karrierestigen min er jeg ikke en direkte utvikler, så artikkelen kan inneholde feil, unøyaktigheter og misforståelser. Lurer du på hvordan analytikere ser hva programmerere og arkitekter gjør? Da velkommen til katt.

Linker

Det første jeg vil begynne med er lenker til eksternt materiale som veiledet meg i prosessen med å skrive denne artikkelen:

Introduksjon

I en tid da solen skinte sterkere og gresset var grønnere, utviklet et team av studenter som forfatteren av denne artikkelen programvare ved å skrive hundrevis av linjer med kode direkte inn i produktgrensesnittet. Noen ganger ble tjenester og ledere brukt til å jobbe med data, og da ble løsningen skaffet ved hjelp av Document-View-mønsteret. Å støtte slik kode krevde enorme kostnader, siden en ny utvikler måtte læres opp (fortelles) hvilken kode som var ansvarlig for hva i produktet, og det var ikke snakk om noen enhetstesting. Utviklingsteamet er 4 personer som sitter i ett rom.
Tiden gikk, arbeidet endret seg. Applikasjonene som ble utviklet ble større og mer komplekse, og fra ett sammensveiset team av utviklere ble det mange forskjellige team av utviklere, arkitekter, brukervennlighetsspesialister, designere og PM-er. Nå er alle ansvarlige for sitt eget område: GUI, forretningslogikk, komponenter. En avdeling for analyse, testing og arkitektur dukket opp. Kostnaden for programvareutvikling har økt hundrevis og til og med tusenvis av ganger. Denne tilnærmingen til utvikling krever en stabil arkitektur som vil synkronisere ulike funksjonelle områder av produktet med hverandre.

Mønstre

Gitt målet om å redusere arbeidskostnadene for utvikling av kompleks programvare, antar vi at det er nødvendig å bruke ferdige enhetlige løsninger. Tross alt letter malede handlinger kommunikasjon mellom utviklere, lar deg referere til kjente design og redusere antall feil.
I følge Wikipedia er et designmønster et repeterbart arkitektonisk design som representerer en løsning på et designproblem innenfor en ofte forekommende kontekst.

La oss starte med den første hovedsaken - Model-View-Controller. MVC er et grunnleggende mønster som har funnet veien inn i mange teknologier, gitt opphav til nye teknologier, og gjør livet enklere for utviklere hver dag.

MVC-mønsteret dukket først opp på SmallTalk-språket. Utviklerne måtte komme med en arkitektonisk løsning som skulle skille det grafiske grensesnittet fra forretningslogikken, og forretningslogikken fra dataene. Dermed består MVC i sin klassiske versjon av tre deler, som gir den navnet. La oss se på dem:

Modell

En modell forstås vanligvis som en del som inneholder den funksjonelle forretningslogikken til en applikasjon. Modellen må være helt uavhengig av resten av produktet. Modelllaget trenger ikke å vite noe om designelementene eller hvordan det skal gjengis. Et resultat oppnås som lar deg endre presentasjonen av data, hvordan de vises, uten å berøre selve modellen.

Modellen har følgende funksjoner:

Modellen er applikasjonens forretningslogikk;
Modellen har kunnskap om seg selv og kjenner ikke til kontrollører og synspunkter;
For noen prosjekter er modellen ganske enkelt et datalag (DAO, database, XML-fil);
For andre prosjekter er modellen en databasebehandler, et sett med objekter eller ganske enkelt applikasjonslogikk;

Utsikt

Ansvaret til visningen inkluderer å vise dataene mottatt fra modellen. Synet kan imidlertid ikke direkte påvirke modellen. Vi kan si at en visning har skrivebeskyttet tilgang til dataene.

Representasjonen har følgende egenskaper:

Visningen implementerer visningen av data som er hentet fra modellen på noen måte;
I noen tilfeller kan visningen ha kode som implementerer noe forretningslogikk.

Eksempler på presentasjon: HTML-side, WPF-skjema, Windows-skjema.

Forskjeller mellom MVC & MVVM & MVP

De vanligste typene MVC-mønster er:

Model-View-Controller
Model-View-Presenter
Modell-View-View-modell

La oss vurdere og sammenligne hver av dem.

Model-View-Presenter

Denne tilnærmingen lar deg lage en representasjonsabstraksjon. For å gjøre dette må du velge et visningsgrensesnitt med et spesifikt sett med egenskaper og metoder. Presentatøren mottar på sin side en referanse til grensesnittimplementeringen, abonnerer på presentasjonshendelser og modifiserer modellen på forespørsel.

Tegn på en programleder:

Visningen samhandler direkte med presentatøren ved å kalle opp passende funksjoner eller hendelser på presentatorforekomsten;
Presentatøren samhandler med visningen ved å bruke et spesielt grensesnitt implementert av visningen;
Én presentatørforekomst er knyttet til én skjerm.

Gjennomføring:
Hver visning må implementere det tilsvarende grensesnittet. Presentasjonsgrensesnittet definerer settet med funksjoner og hendelser som trengs for å samhandle med brukeren (f.eks. IView.ShowErrorMessage(string msg)). Presentatøren må ha en referanse til implementeringen av det tilsvarende grensesnittet, som vanligvis sendes i konstruktøren.
Presentasjonslogikken må ha en referanse til presentatorforekomsten. Alle visningshendelser sendes til presentatøren for behandling og blir nesten aldri behandlet av presentasjonslogikken (inkludert opprettelsen av andre visninger).

Eksempel på bruk: Windows-skjemaer.

Modell-View-View-modell

Denne tilnærmingen lar deg knytte visningselementer til egenskaper og hendelser i visningsmodellen. Det kan hevdes at hvert lag i dette mønsteret ikke vet om eksistensen av et annet lag.

Funksjoner til View-modellen:

Toveis kommunikasjon med presentasjon;
En utsiktsmodell er en abstraksjon av et syn. Betyr vanligvis at egenskapene til visningen er de samme som egenskapene til visningen/modellen
View-modellen har ikke en referanse til view-grensesnittet (IView). Endring av tilstanden til View-modellen endrer automatisk visningen og omvendt, siden databindingsmekanismen brukes (bindinger)
Én forekomst av en visningsmodell er knyttet til én visning.

Gjennomføring:
Når du bruker dette mønsteret, implementerer ikke visningen det tilsvarende grensesnittet (IView).
Visningen må ha en lenke til datakilden (DataContex), som i dette tilfellet er View-modellen. Visningselementer er bundet til de tilsvarende egenskapene og hendelsene til View-modellen.
På sin side implementerer View-modellen et spesielt grensesnitt som brukes til å automatisk oppdatere visningselementer. Et eksempel på et slikt grensesnitt i WPF vil være INotifyPropertyChanged.

Eksempel på bruk: WPF

Model-View-Controller

Hovedideen med dette mønsteret er at både kontrolleren og visningen avhenger av modellen, men modellen er ikke avhengig av disse to komponentene.

Kontrollerens egenskaper

Kontrolleren bestemmer hvilken visning som skal vises for øyeblikket;
Vis hendelser kan bare påvirke kontrolleren. Kontrolleren kan påvirke modellen og definere en annen visning.
Flere visninger er mulig for bare én kontroller;

Gjennomføring:
Kontrolleren avskjærer hendelsen fra utsiden og, i samsvar med logikken innebygd i den, reagerer på denne hendelsen ved å endre modellen ved å kalle den riktige metoden. Etter en endring bruker modellen hendelsen den har endret seg, og alle View-hendelsene som abonnerer på denne, etter å ha mottatt den, vender seg til modellen for oppdaterte data, hvoretter de vises.

Eksempel på bruk: MVC ASP.NET

Sammendrag

Implementeringen av MVVM- og MVP-mønstre ser ved første øyekast ganske enkel og lik ut. For MVVM skjer imidlertid bindingen av visningen til View-modellen automatisk, men for MVP er det nødvendig å programmere
MVC ser ut til å ha mer kontroll over utsikten.

Generelle regler for valg av mønster

MVVM

Brukes i en situasjon der databinding er mulig uten behov for å introdusere spesielle visningsgrensesnitt (dvs. det er ikke nødvendig å implementere IView);
Et vanlig eksempel er WPF-teknologi.

MVP

Brukes i en situasjon der databinding ikke er mulig (Binding kan ikke brukes);
Et vanlig eksempel vil være å bruke Windows Forms.

MVC

Brukes i en situasjon der kommunikasjon mellom visningen og andre deler av applikasjonen ikke er mulig (og du kan ikke bruke MVVM eller MVP);
Et vanlig brukstilfelle er ASP.NET MVC.

Konklusjon

Avslutningsvis vil forfatteren av denne artikkelen påpeke at det å holde seg til bare ett mønster ikke alltid er det beste valget. Tenk deg for eksempel at du vil bruke MVVM til å utvikle applikasjoner ved hjelp av Windows Forms gjennom Bindings-egenskapen til kontroller. Målet ditt er å skille presentasjonen fra forretningslogikken og logikken som forbinder dem. Applikasjonen skal være enkel å teste og støtte, og forståelig for analytikere (tross alt, på spørsmålet "hvordan måles ytelsen til en harddisk" er det bare ett riktig svar - i Joules (abstrakt eksempel Modell -> Visninger)) .

Tusen takk for at du tok deg tid, kos deg med å lese!

Konseptet MVC (Model-View-Controller) har blitt nevnt svært ofte i verden av webprogrammering de siste årene. Alle som på noen måte er knyttet til utviklingen av webapplikasjoner har på en eller annen måte kommet over dette akronymet. I dag vil vi forstå hva MVC-konseptet er og hvorfor det ble populært.

Gammel historie

MVC er ikke et prosjektmønster, det er et designmønster som beskriver hvordan man bygger strukturen til applikasjonen vår, ansvaret og samspillet til hver av delene i denne strukturen.

Det ble først beskrevet i 1979, selvfølgelig, for et annet miljø. Det var ikke noe konsept med en nettapplikasjon den gang. Tim Berners Lee sådde frøene til World Wide Web (WWW) på begynnelsen av nittitallet og forandret verden for alltid. Malen vi bruker i dag er en tilpasning av den originale malen for webutvikling.

Den ville populariteten til denne strukturen i webapplikasjoner skyldtes dens inkludering i to utviklingsmiljøer som ble veldig populære: Struts og Ruby on Rails. Disse to utviklingsmiljøene legger veien for hundrevis av utviklingsmiljøer som ble opprettet senere.

MVC for webapplikasjoner

Ideen bak MVC-designmønsteret er veldig enkel: vi må tydelig skille ansvar for de ulike funksjonene i applikasjonene våre:

Søknaden er delt inn i tre hovedkomponenter som hver har ansvar for ulike oppgaver. La oss se på komponentene i detalj ved å bruke et eksempel.

Kontroller

Kontroller administrerer brukerforespørsler (mottatt som HTTP GET- eller POST-forespørsler når brukeren klikker på grensesnittelementer for å utføre ulike handlinger). Dens hovedfunksjon er å kalle og koordinere handlingen til de nødvendige ressursene og objektene som trengs for å utføre handlinger spesifisert av brukeren. Vanligvis kaller kontrolleren riktig modell for oppgaven og velger riktig visning.

Modell

Modell– Dette er dataene og reglene som brukes for å jobbe med dataene som representerer konseptet med å administrere applikasjonen. I enhver applikasjon er hele strukturen modellert som data som behandles på en bestemt måte. Hva er en bruker for en applikasjon - en melding eller en bok? Kun data som må behandles i henhold til regler (dato kan ikke peke inn i fremtiden, e-post må være i et bestemt format, navn kan ikke være lengre enn X tegn, og så videre).

Modellen gir kontrolleren en representasjon av dataene som brukeren har bedt om (melding, bokside, fotoalbum, etc.). Datamodellen vil være den samme uansett hvordan vi ønsker å presentere den for brukeren. Derfor velger vi en hvilken som helst tilgjengelig visning for å vise dataene.

Modellen inneholder den viktigste delen av logikken i applikasjonen vår, logikken som løser problemet vi har å gjøre med (forum, butikk, bank, etc.). Kontrolleren inneholder i utgangspunktet den organisatoriske logikken for selve applikasjonen (omtrent som housekeeping).

Utsikt

Utsikt gir ulike måter å representere dataene som er hentet fra modellen. Det kan være en mal som er fylt med data. Det kan være flere ulike typer, og kontrolleren velger hvilken som passer best for den aktuelle situasjonen.

En nettapplikasjon består vanligvis av et sett med kontrollere, modeller og visninger. Kontrolleren kan utformes som en hovedkontroller som mottar alle forespørsler og kaller andre kontroller for å utføre handlinger avhengig av situasjonen.

La oss se på et eksempel

La oss si at vi må utvikle en nettbokhandel. Brukeren kan utføre følgende handlinger: se bøker, registrere, kjøpe, legge til varer i gjeldende ordre, opprette eller slette bøker (hvis han er administrator). La oss se hva som skjer når en bruker klikker på en kategori fantasi for å se titlene på bøkene som er tilgjengelige i butikken vår.

Vi har en spesifikk kontroller for å håndtere alle handlinger knyttet til bøker (se, redigere, opprette osv.). La oss kalle det books_controller.php i vårt eksempel. Vi trenger også en modell som book_model.php, som behandler dataene og logikken knyttet til en butikkvare. Avslutningsvis trenger vi flere visninger for å representere dataene, for eksempel en bokliste, en redigeringsside og så videre.

Følgende figur viser hvordan en brukers forespørsel om å se en liste over bøker om et emne behandles fantasi:

Kontrolleren (books_controller.php) mottar brukerforespørselen (HTTP GET eller POST-forespørsel). Vi kan lage en sentral kontroller, for eksempel index.php, som mottar forespørselen og kaller books_controller.php.

Kontrolleren sjekker forespørselen og parameterne og kaller deretter modellen(book_model.php), spør hun har en liste over tilgjengelige bøker om emnet fantasi .

Modellen mottar data fra databasen (eller en annen kilde som lagrer informasjon), bruker filtre og nødvendig logikk, og returnerer deretter data som representerer en liste over bøker.

Kontrolløren bruker riktig visning for å presentere data til brukeren. Hvis forespørselen kommer fra en mobiltelefon, brukes mobiltelefonvisningen; hvis brukeren bruker et bestemt grensesnittdesign, velges den tilsvarende visningen, og så videre.

Hva er fordelene?

Den mest åpenbare fordelen vi får ved å bruke MVC-konseptet er det klare skillet mellom presentasjonslogikk (brukergrensesnitt) og applikasjonslogikk.

Å støtte ulike typer brukere som bruker ulike typer enheter er en vanlig utfordring i disse dager. Grensesnittet som tilbys bør være annerledes hvis forespørselen kommer fra en personlig datamaskin eller fra en mobiltelefon. Modellen returnerer de samme dataene, den eneste forskjellen er at kontrolleren velger forskjellige visninger for å sende ut dataene.

I tillegg til å isolere visninger fra applikasjonslogikk, reduserer MVC-konseptet kompleksiteten til store applikasjoner betydelig. Koden er mye mer strukturert, noe som gjør det enklere å vedlikeholde, teste og gjenbruke løsninger.

Hvorfor bruke arbeidsmiljøet?

Når du bruker arbeidsbenken, er den grunnleggende MVC-strukturen allerede forberedt, og alt du trenger å gjøre er å utvide strukturen ved å plassere filene dine i de riktige katalogene for å matche MVC-mønsteret. I tillegg vil du ha et sett med funksjoner som allerede er skrevet og godt testet.

La oss se på cakePHP som et eksempel på en MVC arbeidsbenk. Etter installasjonen vil du ha tre hovedkataloger:

kake/
leverandører/

Mappe app er der filene dine er plassert. Dette er stedet for å utvikle din del av applikasjonen.

I mappe kake cakePHP-filer (workbench-funksjonalitet) er vert.

Mappe leverandører tjener til å lagre tredjeparts PHP-biblioteker.

Arbeidsområdet ditt (appkatalogen) har følgende struktur:

app/
- config/
- kontrollere/
- lokalitet/
- modeller/
- plugins/
- tester/
- leverandører/
- visninger/
- webroot/

Du må plassere kontrollerene dine i en katalog kontrollere, modeller i katalogen modeller og skriver inn i katalogen visninger!

Når du begynner å bruke arbeidsbenken, vil det umiddelbart bli klart hvor praktisk talt hver del av applikasjonen din som må opprettes eller endres befinner seg. Denne organisasjonen i seg selv forenkler prosessen med å utvikle og vedlikeholde en applikasjon.

Bruker arbeidsbenken for vårt eksempel

Siden denne opplæringen ikke er ment å vise prosessen med å lage en applikasjon ved hjelp av cakePHP, vil vi kun vise koden for modellen, kontrolleren og visningen med kommentarer om fordelene ved å bruke MVC-arbeidsbenken. Koden er bevisst forenklet og uegnet for bruk i en ekte applikasjon.

Husk at vi så på en bokhandel og en nysgjerrig bruker som ønsket å se en komplett liste over bøker om emnet fantasi. Kontrolløren mottok brukerens forespørsel og koordinerte nødvendige handlinger.

Så snart brukeren klikker på knappen, ber nettleseren om den gitte nettadressen:

www.ourstore.com/books/list/fantasy

CakePHP formaterer URL ved hjelp av et mønster /kontroller/handling/param1/param2, Hvor handling er en funksjon som kalles opp av kontrolleren. I den gamle klassiske formen vil url-en se slik ut:

www.ourstore.com/books_controller.php?action=list&category=fantasy

Kontroller

I cakePHP-arbeidsmiljøet vil kontrolleren vår se slik ut:

klasse BooksController utvider AppController (

Funksjonsliste($category) (

$this->set("bøker", $this->Book->findAllByCategory($category));

Funksjon add() ( ... ... )

Funksjonen delete() ( ... ... )

... ... } ?>

Enkelt, ikke sant? Denne kontrolleren vil bli lagret som books_controller.php og lagt inn /app/kontrollere. Den inneholder en liste over funksjoner som utfører handlingene for vårt eksempel, samt andre funksjoner for å utføre bokrelaterte operasjoner (legge til en ny bok, slette en bok, og så videre).

Arbeidsmiljøet gir oss mange ferdige løsninger og vi trenger bare å lage en liste med bøker. Det er en basisklasse som allerede definerer den grunnleggende funksjonaliteten til kontrolleren, så du må arve egenskapene og funksjonene til denne klassen ( AppController er arvingen Kontroller).

Alt du trenger å gjøre i handlingslisten er å ringe modellen for å få dataene og deretter velge en visning for å presentere den for brukeren. Her er hvordan det gjøres.

denne->bok- dette er vår modell, og en del av koden:

$this->Book->findAllByCategory($category)

ber modellen returnere en liste over bøker om det valgte emnet (vi skal se på modellen senere).

Metode sett på linje:

$this->set("bøker", $this->Book->findAllByCategory($category));

Kontrolleren sender data til visningen. Variabel bøker godtar dataene som returneres av modellen og gjør dem tilgjengelige for visningen.

Nå gjenstår det bare å vise visningen, men denne funksjonen gjøres automatisk i cakePHP hvis vi bruker standardvisningen. Hvis vi vil bruke en annen type, må vi eksplisitt kalle metoden gjengi.

Modell

Modellen er enda enklere:

klassebok utvider AppModel (

Hvorfor er det tomt? Fordi den arver fra en basisklasse som gir den nødvendige funksjonaliteten, og vi må bruke CakePHPs navnekonvensjon for å få kjøretiden til å håndtere alle andre oppgaver automatisk. For eksempel vet cakePHP basert på navnet at denne modellen brukes i BooksController, og at den har tilgang til en databasetabell kalt bøker.

Med denne definisjonen vil vi ha en modell som kun kan lese, slette eller lagre data i databasen.

Lagre koden som book.php i mappen /app/modeller.

Utsikt

Alt vi trenger å gjøre nå er å lage en visning (minst én) for handlingslisten. Visningen vil ha HTML-kode og noen få (så få som mulig) linjer med PHP-kode for å gå gjennom utvalget av bøker som modellen gir.

Navn	Forfatter	Pris

Som du kan se, lager visningen ikke en hel side, men bare et fragment av HTML (en tabell i dette tilfellet). Fordi CakePHP gir en annen måte å definere en sidemal på, og visningen settes inn i den malen. Arbeidsbenken gir oss også noen hjelpeobjekter for å utføre vanlige oppgaver mens du lager deler av en HTML-side (sett inn skjemaer, lenker, Ajax eller JavaScript).

Lagre visningen som list.ctp(liste er handlingsnavnet og ctp betyr CakePHP-mal) i mappen /app/visninger/bøker(fordi det er en visning for en kontrollerhandling).

Dette er hvordan alle tre komponentene utføres ved hjelp av CakePHP arbeidsbenken!