Introduktion til MVC-arkitekturen
Den mest populære applikationsarkitektur, som enhver programmør kender til, er MVC . MVC står for Model-View-Controller .
Dette er ikke så meget applikationsarkitekturen som applikationskomponenternes arkitektur, men vi vender tilbage til denne nuance senere. Hvad er MVC?
MVC er et skema til at adskille applikationsdata og kontrollogik i tre separate komponenter - model, visning og controller - så hver komponent kan modificeres uafhængigt.
- Model (model) leverer data og reagerer på controller-kommandoer ved at ændre dens tilstand.
- Visningen er ansvarlig for at vise modeldata til brugeren som reaktion på modelændringer.
- Controlleren (Controlleren) fortolker brugerens handlinger og giver modellen besked om behovet for ændringer.
Denne model blev opfundet tilbage i 1978 (!) År. Ja, problemer med korrekt softwarearkitektur var relevante for 50 år siden. Her er, hvordan denne model er beskrevet af diagrammet i originalen:
Modellen giver data og metoder til at arbejde med dem: forespørgsler til databasen, kontrol af korrekthed. Modellen er uafhængig af visningen (ved ikke, hvordan man gengiver data) og controlleren (har ikke brugerinteraktionspunkter), der giver adgang til og styring af data.
Modellen er bygget på en sådan måde, at den reagerer på anmodninger ved at ændre dens tilstand, og notifikationen af "observatører" kan indbygges. Modellen kan på grund af uafhængighed af den visuelle repræsentation have flere forskellige repræsentationer for én "model".
Visningen er ansvarlig for at hente de nødvendige data fra modellen og sende dem til brugeren. Visningen behandler ikke brugerinput.
Regulatoren sørger for "kommunikationen" mellem brugeren og systemet. Styrer og dirigerer data fra brugeren til systemet og omvendt. Bruger en model og en visning til at implementere den ønskede handling.
Der er en vis vanskelighed med, at denne model har udviklet sig lidt gennem årtierne. Det vil sige, at navnet forblev det samme, men formålet med delene begyndte at ændre sig.
MVC-arkitektur på nettet
Idéen bag MVC-designmønsteret er meget enkel: vi skal klart adskille ansvaret for forskellige adfærd i vores applikationer:
Model— databehandling og applikationslogik.
udsigt— at levere data til brugeren i et hvilket som helst understøttet format.
controller- behandle brugeranmodninger og kalde de relevante ressourcer.
Ansøgningen er opdelt i tre hovedkomponenter, som hver især er ansvarlige for forskellige opgaver. Lad os se nærmere på komponenterne i en klient-server-applikation ved hjælp af et eksempel.
Controller
Brugeren klikker på forskellige elementer på siden i browseren, som følge heraf sender browseren forskellige HTTP-anmodninger: GET, POST eller andre. Controlleren kan inkludere browseren og JS-koden, der virker inde på siden.
Controllerens hovedfunktion i dette tilfælde er at kalde metoder på de nødvendige objekter, administrere adgang til ressourcer for at udføre opgaver specificeret af brugeren. Typisk kalder controlleren den passende model til opgaven og vælger den passende visning.
Model
Model i bred forstand er de data og regler, der bruges til at arbejde med dataene – tilsammen udgør de applikationens forretningslogik. Design af en applikation starter altid med at bygge modeller af de objekter, den opererer på.
Lad os sige, at vi har en online butik, der sælger bøger, er en person så kun en applikationsbruger eller også forfatter til en bog? Disse vigtige spørgsmål skal behandles under modeldesign.
Yderligere er der sæt regler: hvad kan gøres, hvad kan ikke gøres, hvilke datasæt er acceptable og hvilke ikke. Kan en bog eksistere uden en forfatter? Og forfatteren uden bøger? Kan brugerens fødselsdato ligge i år 300 og så videre.
Modellen giver controlleren et overblik over de data, som brugeren har anmodet om (besked, bogside, billeder osv.). Datamodellen vil være den samme, uanset hvordan vi ønsker at præsentere den for brugeren. Derfor vælger vi enhver tilgængelig visning for at vise dataene.
Modellen indeholder den vigtigste del af vores applikationslogik , logikken der løser det problem, vi har med at gøre (forum, butik, bank osv.). Controlleren indeholder for det meste organisatorisk logik for selve applikationen (ligesom din projektleder).
Udsigt
View giver forskellige måder at repræsentere de data, der modtages fra modellen. Det kan være en skabelon, der er fyldt med data. Der kan være flere forskellige synspunkter, og controlleren vælger, hvilken der passer bedst til den aktuelle situation.
En webapplikation består normalt af et sæt controllere, modeller og visninger. Controlleren kan kun være på backend, men der kan også være en variant af flere controllere, når dens logik også er spredt over frontend. Et godt eksempel på denne tilgang er enhver mobilapplikation.
MVC eksempel på nettet
Lad os sige, at du skal udvikle en onlinebutik, der vil sælge bøger. Brugeren kan udføre følgende handlinger: se bøger, registrere, købe, tilføje varer til den aktuelle ordre, markere bøger, han kan lide, og købe dem.
Din ansøgning skal have en model , der er ansvarlig for al forretningslogik. Du har også brug for en controller , der vil behandle alle brugerhandlinger og omdanne dem til metodekald fra forretningslogik. En controllermetode kan dog kalde mange forskellige modelmetoder.
Du har også brug for sæt visninger: en liste over bøger, oplysninger om en bog, en indkøbskurv, en liste over ordrer. Hver side i en webapplikation er faktisk en separat visning, der viser et bestemt aspekt af modellen for brugeren.
Lad os se, hvad der sker, hvis en bruger åbner en liste over anbefalede boghandlere for at se titler. Hele rækkefølgen af handlinger kan beskrives i form af 6 trin:
Trin:
- Brugeren klikker på linket "anbefalet", og browseren sender en anmodning til f.eks. /books/recommendations.
- Controlleren kontrollerer anmodningen : brugeren skal være logget ind. Eller vi burde have samlinger af bøger til ikke-loggede brugere. Controlleren ringer derefter til modellen og beder den returnere listen over bøger, der anbefales til bruger N.
- Modellen tilgår databasen, henter information om bøger derfra: bøger, der er populære i øjeblikket, bøger købt af brugeren, bøger købt af hans venner, bøger fra hans ønskeliste. Baseret på disse data opbygger modellen en liste over 10 anbefalede bøger og returnerer dem til controlleren.
- Controlleren modtager en liste over anbefalede bøger og ser på den. På dette stadium træffer controlleren beslutninger! Hvis der er få bøger, eller listen er helt tom, anmoder den om en liste over bøger for en ulogget bruger. Hvis der er en kampagne i gang lige nu, kan controlleren tilføje salgsfremmende bøger til listen.
- Controlleren bestemmer, hvilken side der skal vises til brugeren. Det kan være en fejlside, en side med en liste over bøger, en side med tillykke med, at brugeren er blevet en millionte besøgende.
- Serveren giver klienten siden ( visning ) valgt af controlleren. Den udfyldes med de nødvendige data (brugernavn, liste over bøger) og går til klienten.
- Klienten modtager siden og viser den til brugeren.
Hvad er fordelene ved denne tilgang?
Den mest åbenlyse fordel, vi får ved at bruge MVC-konceptet, er en klar adskillelse af præsentationslogik (brugergrænseflade) og applikationslogik (backend).
Den anden fordel er opdelingen af serverdelen i to: en smart model ( executor ) og en controller ( beslutningscenter ).
I det foregående eksempel var der et øjeblik, hvor controlleren kunne modtage en tom liste over anbefalede bøger fra modellen og beslutte, hvad den skulle gøre med den. Teoretisk set kunne denne logik sættes direkte ind i modellen.
For det første, når den anmoder om anbefalede bøger, vil modellen beslutte, hvad den skal gøre, hvis listen er tom. Så skulle jeg tilføje koden samme sted, hvad skal jeg gøre hvis der er en kampagne i gang nu, så flere forskellige muligheder.
Så viste det sig, at butiksadministratoren ville se, hvordan brugerens side ville se ud uden en kampagne, eller omvendt, der er ingen kampagne nu, men han vil se, hvordan den fremtidige kampagne vil blive vist. Og der er ingen metoder til dette. Derfor blev det besluttet at adskille beslutningscenteret (controlleren) fra forretningslogikken (modellen).
Ud over at isolere visninger fra applikationslogikken reducerer MVC-konceptet i høj grad kompleksiteten af store applikationer. Koden er meget mere struktureret, hvilket gør det nemmere at vedligeholde, teste og genbruge løsninger.
Når du forstår konceptet med MVC, indser du som udvikler, hvor du skal tilføje sortering af listen over bøger:
- På databaseforespørgselsniveau.
- På niveau med forretningslogik (model).
- På forretningslogikniveau (controller).
- I udsigten - på klientsiden.
Og dette er ikke et retorisk spørgsmål. Tænk lige nu over, hvor og hvorfor du skal tilføje koden for at sortere listen over bøger.
Klassisk MVC-model
Interaktion mellem MVC-komponenter implementeres forskelligt i webapplikationer og mobilapplikationer. Det skyldes, at webappen er kortvarig, behandler én brugeranmodning og afslutter, mens mobilappen behandler mange anmodninger uden at genstarte.
Webapplikationer bruger typisk den "passive" model, mens mobilapplikationer bruger den "aktive" model. Den aktive model, i modsætning til den passive, giver dig mulighed for at abonnere og modtage meddelelser om ændringer i den. Dette er ikke nødvendigt for webapplikationer.
Sådan ser samspillet mellem komponenter i forskellige modeller ud:
Mobilapplikationer (aktiv model) bruger aktivt begivenheder og begivenhedsabonnementsmekanismen. Med denne tilgang abonnerer view ( view ) på modelændringer. Derefter, når en hændelse opstår (f.eks. brugeren klikker på en knap), kaldes controlleren . Det giver også modellen en kommando til at ændre dataene.
Hvis nogle data er ændret, genererer modellen en hændelse om ændring af disse data. Alle visninger, der har abonneret på denne begivenhed (hvor det er vigtigt at ændre denne særlige data) modtager denne begivenhed og opdaterer dataene i deres grænseflade.
I webapplikationer er tingene organiseret lidt anderledes. Den væsentligste tekniske forskel er, at klienten ikke kan modtage meddelelser på serversiden på initiativ af serveren .
Derfor sender en controller i en webapplikation normalt ingen beskeder til visningen, men giver klienten en ny side, som teknisk set er en ny visning eller endda en ny klientapplikation (hvis den ene side ikke ved noget om den anden) .
På nuværende tidspunkt er dette problem delvist løst ved hjælp af følgende tilgange:
- Forespørg regelmæssigt serveren for ændringer af vigtige data (én gang i minuttet eller mere).
- WebSockets giver en klient mulighed for at abonnere på servermeddelelser.
- Web-push-meddelelser fra serversiden.
- HTTP/2-protokollen tillader serveren at starte afsendelsen af meddelelser til klienten.