| Model-View-Controller | |
|---|---|
| Engleză Model-View-Controller | |
| Structura |
|
| Descris în Design Patterns | Nu |
Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") este o schemă pentru separarea datelor aplicației și a logicii de control în trei componente separate: model, vedere și controler - astfel încât modificarea fiecare componentă poate fi realizată independent [1] .
Conceptul de MVC a fost descris de Trygve Reenskaug în 1978 [1] [2] , care lucra la centrul de cercetare Xerox PARC pe limbajul de programare Smalltalk . Mai târziu, Steve Burbeck a implementat modelul în Smalltalk-80 [1] [3] [4] .
Versiunea finală a conceptului MVC a fost publicată abia în 1988 în revista Technology Object [5] .
Ulterior, modelul de design a început să evolueze. De exemplu, a fost introdusă o versiune ierarhică a HMVC ; MVA , MVVM [6] [3] [4] .
O nouă rundă de popularitate a fost adusă de dezvoltarea cadrelor de implementare rapidă în Python , PHP și Ruby : Django , Laravel și , respectiv, Ruby on Rails . La momentul anului 2017, cadrele cu MVC au ocupat o poziție proeminentă în raport cu alte cadre fără acest model [7] .
Odată cu dezvoltarea programării orientate pe obiecte și a conceptului de modele de proiectare , au fost create o serie de modificări ale conceptului MVC, care, atunci când sunt implementate de diferiți autori, pot diferi de original. Deci, de exemplu, Erian Vermi în 2004 a descris un exemplu de MVC generalizat [8] .
În prefața disertației lui Richard Pawson „ Obiecte goale ”, Trygve Reenskaug menționează cea mai veche versiune nepublicată a MVC, conform căreia [9] :
Scopul principal al aplicării acestui concept este de a separa logica afacerii ( modelul ) de vizualizarea acesteia ( vedere , vizualizare ). Datorită acestei separări, crește posibilitatea reutilizarii codului . Acest concept este cel mai util atunci când utilizatorul trebuie să vadă aceleași date în același timp în contexte diferite și/sau din puncte de vedere diferite. În special, sunt îndeplinite următoarele sarcini:
Conceptul MVC vă permite să separați modelul, vizualizarea și controlerul în trei componente separate:
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ă redeze datele) și de controler (nu are puncte de interacțiune cu utilizatorul), oferind doar acces și manipulare a 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ă intrarea utilizatorului [10] .
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ă.
Deoarece MVC nu are o implementare strictă, poate fi implementat în moduri diferite. Nu există o definiție general acceptată a locului în care ar trebui să fie localizată logica de afaceri. Poate fi atât în controler, cât și în model. În acest din urmă caz, modelul va conține toate obiectele de afaceri cu toate datele și funcțiile.
Unele cadre definesc în mod rigid unde ar trebui plasată logica de afaceri, altele nu au astfel de reguli.
De asemenea, nu este specificat unde ar trebui să fie localizată validarea datelor introduse de utilizator. Validările simple pot apărea chiar și într-o vizualizare, dar sunt mai frecvente într-un controler sau model.
De asemenea, internaționalizarea și formatarea datelor nu dispun de o îndrumare clară privind locația.
Pentru a implementa schema „Model-View-Controller”, se utilizează un număr destul de mare de modele de proiectare (în funcție de complexitatea soluției arhitecturale), dintre care principalele sunt „ observator ”, „ strategie ”, „ linker ” [11]. ] .
Cea mai tipică implementare este cea în care vederea este separată de model prin stabilirea unui protocol de interacțiune între ele care utilizează „aparatul de evenimente” (desemnarea prin „evenimente” a anumitor situații care apar în timpul execuției programului și trimiterea de notificări despre le-o tuturor celor care s-au abonat pentru a primi): pentru fiecare modificare specifică a datelor interne din model (notate ca „eveniment”), notifică acele vizualizări care depind de el care sunt abonate pentru a primi o astfel de notificare - iar vizualizarea este la curent. Acesta este modul în care este folosit modelul „ observator ” .
La procesarea reacției utilizatorului, vizualizarea selectează, în funcție de reacție, controlerul dorit , care va asigura una sau alta conexiune cu modelul. Pentru aceasta, se folosește modelul „ strategie ” sau poate exista o modificare folosind în schimb modelul „ comandă ” .
Pentru posibilitatea aceluiași tip de manipulare a subobiectelor de tip ierarhic complex-compozit, se poate folosi șablonul „ linker ” . În plus, pot fi utilizate și alte modele de design - de exemplu, „ metoda din fabrică ”, care vă va permite să setați tipul de controler implicit pentru vizualizarea corespunzătoare.
Programatorii începători interpretează foarte des modelul arhitectural MVC ca un model MVC pasiv: modelul acționează numai ca un set de funcții pentru accesarea datelor, iar controlerul conține logica de afaceri . Ca rezultat, codul modelului este de fapt un mijloc de obținere a datelor din DBMS , iar controlerul este un modul tipic plin cu logica de afaceri. Ca urmare a acestei înțelegeri, dezvoltatorii MVC au început să scrie cod pe care Padrigue Brady (cunoscut în cercurile comunității Zend Framework ) l-a descris drept „TTUK” („Fat Stupid Ugly Controllers”; Fat Stupid Ugly Controllers):
TTUK obișnuit a obținut date dintr-o bază de date (folosind un strat de abstractizare a bazei de date, pretinzând că este un model) sau a manipulat, validat, scrierea și transmiterea datelor către o vizualizare. Această abordare a devenit foarte populară deoarece utilizarea unor astfel de controlere este similară cu practica clasică de a folosi un fișier php separat pentru fiecare pagină a aplicației.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ M în MVC: De ce modelele sunt greșit înțelese și neapreciateDar în programarea orientată pe obiecte se folosește modelul activ [12] MVC, unde modelul nu este doar o combinație de cod de acces la date și DBMS , ci și întreaga logică de afaceri ; modelele pot, de asemenea, să încapsuleze alte modele în sine. Controlorii, ca elemente ale unui sistem informatic , sunt responsabili doar pentru:
Numai în acest caz, controlerul devine „subțire” și îndeplinește exclusiv funcția de legătură (strat de adeziv) între componentele individuale ale sistemului informațional .