Introducere în arhitectura MVC
Cea mai populară arhitectură de aplicații despre care știe fiecare programator este MVC . MVC înseamnă Model-View-Controller .
Aceasta nu este atât arhitectura aplicațiilor, cât arhitectura componentelor aplicației, dar vom reveni la această nuanță mai târziu. Ce este MVC?
MVC este o schemă pentru separarea datelor aplicației și a logicii de control în trei componente separate - model, vizualizare și controler - astfel încât fiecare componentă să poată fi modificată independent.
- Modelul (Modelul) furnizează date și răspunde la comenzile controlerului schimbându-și starea.
- Vizualizarea este responsabilă pentru afișarea datelor de model către utilizator ca răspuns la modificările modelului.
- Controllerul (Controllerul) interpretează acțiunile utilizatorului, notificând modelul despre necesitatea modificărilor.
Acest model a fost inventat în 1978 (!) Anul. Da, problemele cu arhitectura software adecvată erau relevante acum 50 de ani. Iată cum este descris acest model de diagrama din original:
Modelul oferă date și metode de lucru cu acestea: interogări la baza de date, verificarea corectitudinii. Modelul este independent de vizualizare (nu știe cum să reda datele) și de controlor (nu are puncte de interacțiune cu utilizatorul), oferind acces la și gestionarea datelor.
Modelul este construit în așa fel încât să răspundă solicitărilor prin schimbarea stării sale, iar notificarea „observatorilor” poate fi încorporată. Modelul, datorită independenței față de reprezentarea vizuală, poate avea mai multe reprezentări diferite pentru un „model”.
Vizualizarea este responsabilă pentru obținerea datelor necesare din model și trimiterea acestora către utilizator. Vizualizarea nu procesează introducerea utilizatorului.
Controlerul asigură „comunicarea” între utilizator și sistem. Controlează și direcționează datele de la utilizator către sistem și invers. Utilizează un model și o vedere pentru a implementa acțiunea dorită.
Există o anumită dificultate cu faptul că acest model a evoluat puțin de-a lungul deceniilor. Adică numele a rămas același, dar scopul pieselor a început să se schimbe.
Arhitectura MVC pe web
Ideea din spatele modelului de design MVC este foarte simplă: trebuie să separăm în mod clar responsabilitatea pentru diferitele comportamente din aplicațiile noastre:
Model— procesarea datelor și logica de aplicare.
vedere— furnizarea de date utilizatorului în orice format acceptat.
controlor- procesarea cererilor utilizatorilor și apelarea resurselor corespunzătoare.
Aplicația este împărțită în trei componente principale, fiecare dintre acestea fiind responsabilă pentru diferite sarcini. Să aruncăm o privire mai atentă asupra componentelor unei aplicații client-server folosind un exemplu.
Controlor
Utilizatorul face clic pe diverse elemente din pagină din browser, în urma cărora browserul trimite diverse solicitări HTTP: GET, POST sau altele. Controlerul poate include browserul și codul JS care funcționează în interiorul paginii.
Funcția principală a controlerului în acest caz este de a apela metode pe obiectele necesare, de a gestiona accesul la resurse pentru a îndeplini sarcinile specificate de utilizator. De obicei, controlorul apelează modelul adecvat pentru sarcină și selectează vizualizarea corespunzătoare.
Model
Modelul într-un sens larg este datele și regulile care sunt utilizate pentru a lucra cu datele - împreună ele alcătuiesc logica de afaceri a aplicației. Proiectarea unei aplicații începe întotdeauna cu construirea de modele ale obiectelor pe care operează.
Să presupunem că avem un magazin online care vinde cărți, atunci o persoană este doar un utilizator de aplicație sau, de asemenea, un autor al unei cărți? Aceste întrebări importante trebuie abordate în timpul proiectării modelului.
În plus, există seturi de reguli: ce se poate face, ce nu se poate face, ce seturi de date sunt acceptabile și care nu. Poate exista o carte fără autor? Și autorul fără cărți? Data nașterii utilizatorului poate fi în anul 300 și așa mai departe.
Modelul oferă controlorului o vizualizare a datelor pe care utilizatorul le-a solicitat (mesaj, pagină de carte, imagini etc.). Modelul de date va fi același, indiferent de modul în care dorim să-l prezentăm utilizatorului. Prin urmare, alegem orice vizualizare disponibilă pentru a afișa datele.
Modelul conține cea mai importantă parte a logicii aplicației noastre , logica care rezolvă problema cu care ne confruntăm (forum, magazin, bancă etc.). Controlerul conține în principal logica organizațională pentru aplicația în sine (la fel ca managerul de proiect).
Vedere
Vizualizare oferă diferite moduri de a reprezenta datele care sunt primite de la model. Poate fi un șablon care este umplut cu date. Pot exista mai multe vederi diferite, iar controlerul alege care este cea mai bună pentru situația actuală.
O aplicație web constă de obicei dintr-un set de controlere, modele și vizualizări. Controlerul poate fi doar pe backend, dar poate exista și o variantă a mai multor controlere, când logica sa este răspândită și pe front. Un bun exemplu al acestei abordări este orice aplicație mobilă.
Exemplu MVC pe web
Să presupunem că trebuie să dezvoltați un magazin online care să vândă cărți. Utilizatorul poate efectua următoarele acțiuni: vizualizarea cărților, înregistrarea, cumpărarea, adăugarea articolelor la comanda curentă, marcarea cărților care îi plac și cumpărarea acestora.
Aplicația dvs. ar trebui să aibă un model care este responsabil pentru toată logica de afaceri. De asemenea, aveți nevoie de un controler care va procesa toate acțiunile utilizatorului și le va transforma în apeluri de metodă din logica de afaceri. Cu toate acestea, o metodă de controler poate apela multe metode de model diferite.
De asemenea, aveți nevoie de seturi de vizualizări: o listă de cărți, informații despre o carte, un coș de cumpărături, o listă de comenzi. Fiecare pagină a unei aplicații web este de fapt o vizualizare separată care afișează utilizatorului un anumit aspect al modelului.
Să vedem ce se întâmplă dacă un utilizator deschide o listă de cărți recomandate de librărie pentru a vedea titluri. Întreaga secvență de acțiuni poate fi descrisă sub forma a 6 pași:
Pași:
- Utilizatorul face clic pe linkul „recomandat” și browserul trimite o solicitare la, de exemplu, /books/recommendations.
- Controlorul verifică cererea : utilizatorul trebuie să fie autentificat. Sau ar trebui să avem colecții de cărți pentru utilizatorii neconectați. Controlorul sună apoi modelul și îi cere să returneze lista de cărți recomandate utilizatorului N.
- Modelul accesează baza de date, preia informații despre cărți de acolo: cărți care sunt populare în prezent, cărți cumpărate de utilizator, cărți cumpărate de prietenii săi, cărți din lista lui de dorințe. Pe baza acestor date, modelul construiește o listă cu 10 cărți recomandate și le returnează controlorului.
- Controlerul primește o listă de cărți recomandate și se uită la ea. În această etapă, controlorul ia decizii! Dacă sunt puține cărți sau lista este complet goală, atunci solicită o listă de cărți pentru un utilizator nelogat. Dacă are loc o promovare chiar acum, controlorul poate adăuga cărți promoționale pe listă.
- Controlerul determină ce pagină să arate utilizatorului. Poate fi o pagină de eroare, o pagină cu o listă de cărți, o pagină care felicită că utilizatorul a devenit al milionul de vizitator.
- Serverul oferă clientului pagina ( vizualizare ) selectată de controler. Se completează cu datele necesare (nume de utilizator, listă de cărți) și merge la client.
- Clientul primește pagina și o afișează utilizatorului.
Care sunt beneficiile acestei abordări?
Cel mai evident avantaj pe care îl obținem în urma utilizării conceptului MVC este o separare clară a logicii prezentării (interfața utilizator) și logica aplicației (backend).
Al doilea avantaj este împărțirea părții server în două: un model inteligent ( executor ) și un controler ( centrul de decizie ).
În exemplul anterior, a existat un moment în care controlerul putea primi o listă goală de cărți recomandate de la model și putea decide ce să facă cu ea. Teoretic, această logică ar putea fi introdusă direct în model.
În primul rând, atunci când solicită cărți recomandate, modelul ar decide ce să facă dacă lista este goală. Apoi ar trebui să adaug codul în același loc, ce să fac dacă există o promovare acum, apoi mai multe opțiuni diferite.
Apoi s-a dovedit că administratorul magazinului a vrut să vadă cum ar arăta pagina utilizatorului fără promovare, sau invers, nu există nicio promovare acum, dar vrea să vadă cum va fi afișată promoția viitoare. Și nu există metode pentru asta. Prin urmare, s-a decis separarea centrului de decizie (controller) de logica de business (model).
Pe lângă izolarea vizualizărilor de logica aplicației, conceptul MVC reduce foarte mult complexitatea aplicațiilor mari. Codul este mult mai structurat, ceea ce facilitează întreținerea, testarea și reutilizarea soluțiilor.
Înțelegând conceptul de MVC, tu, ca dezvoltator, realizezi unde trebuie să adaugi sortarea listei de cărți:
- La nivel de interogare a bazei de date.
- La nivelul logicii de afaceri (model).
- La nivel de logica de afaceri (controller).
- În vedere - pe partea clientului.
Și aceasta nu este o întrebare retorică. În acest moment, gândiți-vă unde și de ce trebuie să adăugați codul pentru sortarea listei de cărți.
Model clasic MVC
Interacțiunea dintre componentele MVC este implementată diferit în aplicațiile web și aplicațiile mobile. Acest lucru se datorează faptului că aplicația web este de scurtă durată, procesează o cerere de utilizator și iese, în timp ce aplicația mobilă procesează multe solicitări fără a reporni.
Aplicațiile web folosesc de obicei modelul „pasiv”, în timp ce aplicațiile mobile folosesc modelul „activ”. Modelul activ, spre deosebire de cel pasiv, vă permite să vă abonați și să primiți notificări cu privire la modificările acestuia. Acest lucru nu este necesar pentru aplicațiile web.
Iată cum arată interacțiunea componentelor din diferite modele:
Aplicațiile mobile (model activ) folosesc în mod activ evenimentele și mecanismul de abonare la evenimente. Cu această abordare, vizualizarea ( vizualizarea ) se abonează la modificările modelului. Apoi, când are loc un eveniment (de exemplu, utilizatorul face clic pe un buton), controlerul este numit . De asemenea, oferă modelului o comandă pentru a schimba datele.
Dacă unele date s-au modificat, atunci modelul generează un eveniment despre modificarea acestor date. Toate vizualizările care s-au abonat la acest eveniment (pentru care este important să se modifice aceste date particulare) primesc acest eveniment și actualizează datele în interfața lor.
În aplicațiile web, lucrurile sunt organizate puțin diferit. Principala diferență tehnică este că clientul nu poate primi mesaje pe partea serverului din inițiativa serverului .
Prin urmare, un controler dintr-o aplicație web de obicei nu trimite niciun mesaj către vizualizare, ci oferă clientului o pagină nouă, care este din punct de vedere tehnic o vizualizare nouă sau chiar o nouă aplicație client (dacă o pagină nu știe nimic despre cealaltă) .
În prezent, această problemă este parțial rezolvată folosind următoarele abordări:
- Interogați regulat serverul pentru modificări ale datelor importante (o dată pe minut sau mai mult).
- WebSocket-urile permit unui client să se aboneze la mesajele serverului.
- Notificări push web din partea serverului.
- Protocolul HTTP/2 permite serverului să inițieze trimiterea de mesaje către client.