MVC-tilnærming

Introduksjon til MVC-arkitekturen

Den mest populære applikasjonsarkitekturen som alle programmerere kjenner til er MVC . MVC står for Model-View-Controller .

Dette er ikke så mye arkitekturen til applikasjoner som arkitekturen til applikasjonskomponenter, men vi kommer tilbake til denne nyansen senere. Hva er MVC?

MVC er et opplegg for å separere applikasjonsdata og kontrolllogikk i tre separate komponenter – modell, visning og kontroller – slik at hver komponent kan modifiseres uavhengig.

• Modell (modell) gir data og reagerer på kontrollkommandoer ved å endre tilstanden.
• Visningen er ansvarlig for å vise modelldata til brukeren som svar på modellendringer.
• Kontrolleren (kontrolleren) tolker handlingene til brukeren, og gir modellen beskjed om behovet for endringer.

Denne modellen ble oppfunnet tilbake i 1978 (!) År. Ja, problemer med riktig programvarearkitektur var aktuelle for 50 år siden. Her er hvordan denne modellen er beskrevet av diagrammet i originalen:

Modellen gir data og metoder for å jobbe med dem: spørringer til databasen, kontroll av korrekthet. Modellen er uavhengig av visningen (vet ikke hvordan data skal gjengis) og kontrolleren (har ikke brukerinteraksjonspunkter), og gir tilgang til og administrasjon av data.

Modellen er bygget på en slik måte at den svarer på forespørsler ved å endre tilstanden, og varslingen til "observatører" kan bygges inn. Modellen kan, på grunn av uavhengighet fra den visuelle representasjonen, ha flere forskjellige representasjoner for én "modell".

Visningen er ansvarlig for å hente nødvendige data fra modellen og sende dem til brukeren. Visningen behandler ikke brukerinndata.

Kontrolleren sørger for "kommunikasjonen" mellom brukeren og systemet. Styrer og dirigerer data fra brukeren til systemet og omvendt. Bruker en modell og en visning for å gjennomføre ønsket handling.

Det er en viss vanskelighet med det faktum at denne modellen har utviklet seg litt i løpet av tiårene. Det vil si at navnet forble det samme, men formålet med delene begynte å endre seg.

MVC-arkitektur på nettet

Ideen bak MVC-designmønsteret er veldig enkel: vi må tydelig skille ansvaret for forskjellig oppførsel i applikasjonene våre:

Modell— databehandling og applikasjonslogikk.

utsikt— gi data til brukeren i alle støttede formater.

kontrolleren- behandle brukerforespørsler og ringe de aktuelle ressursene.

Søknaden er delt inn i tre hovedkomponenter som hver har ansvar for ulike oppgaver. La oss se nærmere på komponentene i en klient-serverapplikasjon ved å bruke et eksempel.

Kontroller

Brukeren klikker på ulike elementer på siden i nettleseren, som et resultat av at nettleseren sender ulike HTTP-forespørsler: GET, POST eller andre. Kontrolleren kan inkludere nettleseren og JS-koden som fungerer inne på siden.

Hovedfunksjonen til kontrolleren i dette tilfellet er å kalle metoder på de nødvendige objektene, administrere tilgang til ressurser for å utføre oppgaver spesifisert av brukeren. Vanligvis kaller kontrolleren riktig modell for oppgaven og velger riktig visning.

Modell

Modell i vid forstand er dataene og reglene som brukes for å jobbe med dataene – sammen utgjør de forretningslogikken til applikasjonen. Å designe en applikasjon starter alltid med å bygge modeller av objektene den opererer på.

La oss si at vi har en nettbutikk som selger bøker, så er en person bare en applikasjonsbruker eller også forfatter av en bok? Disse viktige spørsmålene må tas opp under modelldesign.

Videre er det sett med regler: hva kan gjøres, hva kan ikke gjøres, hvilke datasett er akseptable og hvilke ikke. Kan en bok eksistere uten en forfatter? Og forfatteren uten bøker? Kan brukerens fødselsdato være i år 300 og så videre.

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

Modellen inneholder den viktigste delen av applikasjonslogikken vår , logikken som løser problemet vi har å gjøre med (forum, butikk, bank, etc.). Kontrolleren inneholder for det meste organisatorisk logikk for selve applikasjonen (akkurat som din prosjektleder).

Utsikt

View gir ulike måter å representere dataene som mottas fra modellen. Det kan være en mal som er fylt med data. Det kan være flere forskjellige visninger og kontrolløren velger hvilken som er best for den aktuelle situasjonen.

En nettapplikasjon består vanligvis av et sett med kontrollere, modeller og visninger. Kontrolleren kan bare være på backend, men det kan også være en variant av flere kontrollere, når logikken er spredt over frontend også. Et godt eksempel på denne tilnærmingen er enhver mobilapplikasjon.

MVC eksempel på nettet

La oss si at du må utvikle en nettbutikk som selger bøker. Brukeren kan utføre følgende handlinger: se bøker, registrere, kjøpe, legge til varer i gjeldende bestilling, merke bøker han liker og kjøpe dem.

Søknaden din bør ha en modell som er ansvarlig for all forretningslogikk. Du trenger også en kontroller som behandler alle brukerhandlinger og gjør dem om til metodeanrop fra forretningslogikk. En kontrollermetode kan imidlertid kalle mange forskjellige modellmetoder.

Du trenger også sett med visninger: en liste over bøker, informasjon om én bok, en handlekurv, en liste over bestillinger. Hver side i en nettapplikasjon er faktisk en egen visning som viser et bestemt aspekt av modellen til brukeren.

La oss se hva som skjer hvis en bruker åpner en liste over anbefalte bøker for å se titler. Hele sekvensen av handlinger kan beskrives i form av 6 trinn:

Trinn:

1. Brukeren klikker på "anbefalt"-lenken og nettleseren sender en forespørsel til for eksempel /books/recommendations.
2. Kontrolleren sjekker forespørselen : brukeren må være pålogget. Eller vi bør ha samlinger av bøker for ikke-påloggede brukere. Kontrolleren ringer deretter modellen og ber den returnere listen over bøker som er anbefalt til bruker N.
3. Modellen får tilgang til databasen, henter informasjon om bøker derfra: bøker som er populære for øyeblikket, bøker kjøpt av brukeren, bøker kjøpt av venner, bøker fra ønskeliste. Basert på disse dataene bygger modellen en liste over 10 anbefalte bøker og returnerer dem til kontrolleren.
4. Kontrolleren mottar en liste over anbefalte bøker og ser på den. På dette stadiet tar kontrolløren beslutninger! Hvis det er få bøker eller listen er helt tom, ber den om en liste over bøker for en ulogget bruker. Hvis det pågår en kampanje akkurat nå, kan kontrolleren legge til kampanjebøker på listen.
5. Kontrolleren bestemmer hvilken side som skal vises til brukeren. Det kan være en feilside, en side med en liste over bøker, en side som gratulerer med at brukeren har blitt en millionbesøkende.
6. Serveren gir klienten siden ( visning ) valgt av kontrolleren. Den fylles med nødvendige data (brukernavn, liste over bøker) og går til klienten.
7. Klienten mottar siden og viser den til brukeren.

Hva er fordelene med denne tilnærmingen?

Den mest åpenbare fordelen vi får ved å bruke MVC-konseptet er en klar skille mellom presentasjonslogikk (brukergrensesnitt) og applikasjonslogikk (backend).

Den andre fordelen er delingen av serverdelen i to: en smart modell ( utfører ) og en kontroller ( beslutningssenter ).

I det forrige eksemplet var det et øyeblikk da kontrolleren kunne motta en tom liste over anbefalte bøker fra modellen og bestemme hva den skulle gjøre med den. Teoretisk sett kan denne logikken settes direkte inn i modellen.

For det første, når du ber om anbefalte bøker, vil modellen bestemme hva den skal gjøre hvis listen er tom. Da må jeg legge til koden på samme sted, hva skal jeg gjøre hvis det er en kampanje på gang nå, så flere forskjellige alternativer.

Så viste det seg at butikkadministratoren ønsket å se hvordan brukerens side ville se ut uten en kampanje, eller omvendt, det er ingen kampanje nå, men han ønsker å se hvordan den fremtidige kampanjen vil bli vist. Og det finnes ingen metoder for dette. Derfor ble det besluttet å skille beslutningssenteret (kontrolleren) fra forretningslogikken (modellen).

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

Når du forstår konseptet med MVC, innser du som utvikler hvor du trenger å legge til sortering av bøker:

• På databasespørringsnivå.
• På nivå med forretningslogikk (modell).
• På forretningslogikknivå (kontroller).
• I visningen - på klientsiden.

Og dette er ikke et retorisk spørsmål. Akkurat nå, tenk på hvor og hvorfor du må legge til koden for å sortere listen over bøker.

Klassisk MVC-modell

Interaksjon mellom MVC-komponenter implementeres forskjellig i webapplikasjoner og mobilapplikasjoner. Dette er fordi nettappen er kortvarig, behandler én brukerforespørsel og avslutter, mens mobilappen behandler mange forespørsler uten å starte på nytt.

Nettapplikasjoner bruker vanligvis den "passive" modellen, mens mobilapplikasjoner bruker den "aktive" modellen. Den aktive modellen, i motsetning til den passive, lar deg abonnere og motta varsler om endringer i den. Dette er ikke nødvendig for nettapplikasjoner.

Slik ser samspillet mellom komponenter i ulike modeller ut:

Mobilapplikasjoner (aktiv modell) bruker aktivt arrangementer og arrangementsabonnementsmekanismen. Med denne tilnærmingen abonnerer view ( view ) på modellendringer. Deretter, når en hendelse inntreffer (for eksempel brukeren klikker på en knapp), kalles kontrolleren . Det gir også modellen en kommando for å endre dataene.

Hvis noen data har endret seg, genererer modellen en hendelse om endring av disse dataene. Alle visninger som har abonnert på denne hendelsen (som det er viktig å endre denne spesielle dataen for) mottar denne hendelsen og oppdaterer dataene i deres grensesnitt.

I nettapplikasjoner er ting organisert litt annerledes. Den viktigste tekniske forskjellen er at klienten ikke kan motta meldinger på serversiden på initiativ fra serveren .

Derfor sender en kontroller i en nettapplikasjon vanligvis ingen meldinger til visningen, men gir klienten en ny side, som teknisk sett er en ny visning eller til og med en ny klientapplikasjon (hvis den ene siden ikke vet noe om den andre) .

På det nåværende tidspunkt er dette problemet delvis løst ved å bruke følgende tilnærminger:

• Kontroller serveren regelmessig for endringer i viktige data (en gang i minuttet eller mer).
• WebSockets lar en klient abonnere på servermeldinger.
• Web-push-varsler fra serversiden.
• HTTP/2-protokollen lar serveren starte sending av meldinger til klienten.