Modele pentru începători: MVC vs MVP vs MVVM. Crearea elementelor HTML

Ultima actualizare: 31.10.2015

Controlerul este componenta centrală în arhitectura MVC. Controlerul primește intrarea utilizatorului, o procesează și trimite înapoi rezultatul prelucrării, de exemplu, sub formă de vizualizare.

Există unele convenții când se utilizează controlere. Deci, conform convențiilor de denumire, numele controlerului trebuie să se încheie cu sufixul „Controller”, iar restul înainte de acest sufix este considerat numele controlerului.

Pentru a contacta controlerul dintr-un browser web, trebuie să introducem în bara de adrese adresa_site/nume_controller/. Deci, la cerere site_address/Home/, sistemul de rutare implicit va apela metoda Index a HomeController pentru a procesa cererea de intrare. Dacă dorim să trimitem o solicitare către o anumită metodă de controler, atunci trebuie să specificăm această metodă în mod explicit: adresa_site-ului/numele_controllerului/metoda_controllerului, De exemplu, site_address/Home/Buy- apelarea metodei Buy a controlerului HomeController.

Controlerul este o clasă obișnuită care moștenește din clasa de bază System.Web.Mvc.Controller. La rândul său, clasa Controller implementează clasa de bază abstractă ControllerBase și prin aceasta interfața IController. Astfel, formal, pentru a vă crea propria clasă de controler, este suficient să creați o clasă care să implementeze interfața IController și să aibă sufixul în nume Controlor.

Interfața IController definește o singură metodă Execute, care este responsabilă pentru procesarea contextului cererii:

Interfață publică IController ( void Execute(RequestContext requestContext); )

Acum să creăm un controler simplu care implementează această interfață. Ca proiect, putem prelua proiectul din capitolul anterior. Deci, să adăugăm o nouă clasă în folderul Controllers al proiectului (și anume o clasă, nu un controler) cu următorul conținut:

Utilizarea System.Web.Mvc; folosind System.Web.Routing; namespace BookStore.Controllers ( clasă publică MyController: IController ( public void Execute(RequestContext requestContext) ( șir ip = requestContext.HttpContext.Request.UserHostAddress; var răspuns = requestContext.HttpContext.Response; response.Write("

Adresa dvs. IP: " + ip + "

"); } } }

La accesarea oricărui controler, sistemul îi transmite contextul solicitării acestuia. Acest context de solicitare include totul: cookie-uri, trimiteri de formulare, șiruri de interogări, acreditări de utilizator etc. Implementarea interfeței IController vă permite să obțineți acest context de solicitare în metoda Execute prin parametrul RequestContext. În cazul nostru, obținem adresa IP a utilizatorului prin proprietatea requestContext.HttpContext.Request.UserHostAddress.

În plus, putem trimite un răspuns utilizatorului folosind obiectul Response și metoda sa Write.

Astfel, urmând calea site_address/My/, utilizatorul își va vedea adresa IP.

Deși este foarte ușor să creați controlere folosind implementarea interfeței IController, în realitate este mai frecvent să operați cu clase de nivel superior, cum ar fi clasa Controller, deoarece oferă mijloace mai puternice pentru gestionarea cererilor. Și dacă la implementarea interfeței IController avem de-a face cu o singură metodă Execute și toate cererile către acest controlor vor fi procesate printr-o singură metodă, atunci când moștenim clasa Controller putem crea multe metode de acțiune care vor fi responsabile pentru procesarea cererilor primite și returnează rezultate diferite ale acțiunilor.

Pentru a crea un controler standard, putem adăuga și o clasă simplă în folderul Controllers și să moștenim din clasa Controller, de exemplu:

Utilizarea System.Web.Mvc; namespace BookStore.Controllers ( clasă publică BookShopController: Controller ( public ActionResult Index() ( return View(); ) ) )

Cu toate acestea, Visual Studio ne oferă instrumente mai convenabile pentru crearea de controlere, permițând configurarea flexibilă a acestora. Pentru a le folosi, faceți clic dreapta pe folderul Controlere și selectați din meniul care apare Adăugați -> Controler.... După aceasta, ni se va prezenta o fereastră pentru crearea unui nou controler:

De fapt, primele trei puncte de aici sunt legate direct de controlerele MVC 5. Restul sunt mai mult legate de Web API 2. În această listă, selectați primul element - MVC 5 Controller - Empty, ceea ce implică crearea unui controler gol. Cele două puncte rămase vă permit să generați clase cu funcționalitate CRUD pe baza șabloanelor de generare, despre care vom vorbi în secțiunea despre modele.

În continuare ni se va cere să introducem un nume, iar după aceea un nou controler cu o singură metodă Index va fi adăugat la proiect. Cu această adăugare, spre deosebire de exemplele anterioare, un director va fi creat automat pentru acest controler în folderul Vizualizări, care va stoca toate vizualizările asociate cu acțiunile acestui controler.

Bună ziua, dragi colegi. În acest articol, aș dori să vorbesc despre înțelegerea mea analitică a diferențelor dintre modelele MVC, MVP și MVVM. Am fost îndemnat să scriu acest articol de dorința de a înțelege abordările moderne ale dezvoltării de software mari și caracteristicile arhitecturale corespunzătoare. În stadiul actual al carierei mele, nu sunt un dezvoltator direct, așa că articolul poate conține erori, inexactități și neînțelegeri. Intrigat de modul în care analiștii văd ce fac programatorii și arhitecții? Atunci bun venit la cat.

Legături

Primul lucru cu care aș dori să încep sunt link-urile către materiale externe care m-au ghidat în procesul de scriere a acestui articol:

Introducere

Într-o perioadă în care soarele strălucea mai puternic și iarba era mai verde, o echipă de studenți precum autorul acestui articol a dezvoltat un software prin scrierea a sute de linii de cod direct în interfața produsului. Uneori, serviciile și managerii erau folosiți pentru a lucra cu date, iar apoi soluția a fost obținută folosind modelul Document-View. Sprijinirea unui astfel de cod a necesitat costuri enorme, deoarece un nou dezvoltator trebuia instruit (spus) ce cod era responsabil pentru ce din produs și nu se vorbea despre nicio testare unitară. Echipa de dezvoltare este formată din 4 persoane care stau într-o cameră.
Timpul a trecut, munca s-a schimbat. Aplicațiile dezvoltate au devenit mai mari și mai complexe, iar dintr-o echipă coerentă de dezvoltatori au devenit multe echipe diferite de dezvoltatori, arhitecți, specialiști în utilizare, designeri și PM. Acum fiecare este responsabil pentru propria sa zonă: GUI, logica de afaceri, componente. A apărut un departament de analiză, testare și arhitectură. Costul dezvoltării software a crescut de sute și chiar de mii de ori. Această abordare a dezvoltării necesită o arhitectură stabilă care să sincronizeze diferite zone funcționale ale produsului între ele.

Modele

Având în vedere scopul de a reduce costurile forței de muncă pentru dezvoltarea de software complex, presupunem că este necesar să se utilizeze soluții unificate gata făcute. La urma urmei, acțiunile șablon facilitează comunicarea între dezvoltatori, vă permit să vă referiți la modele binecunoscute și reduceți numărul de erori.
Potrivit Wikipedia, un model de design este un design arhitectural repetabil care reprezintă o soluție la o problemă de design într-un context care apare frecvent.

Să începem cu primul lucru principal - Model-View-Controller. MVC este un model fundamental care și-a găsit drumul în multe tehnologii, a dat naștere la noi tehnologii și le face viața mai ușoară pentru dezvoltatori în fiecare zi.

Modelul MVC a apărut pentru prima dată în limbajul SmallTalk. Dezvoltatorii au trebuit să vină cu o soluție arhitecturală care să separe interfața grafică de logica de afaceri și logica de afaceri de date. Astfel, în versiunea sa clasică, MVC este format din trei părți, care îi dau numele. Să ne uităm la ele:

Model

Un model este de obicei înțeles ca o parte care conține logica funcțională de afaceri a unei aplicații. Modelul trebuie să fie complet independent de restul produsului. Stratul model nu trebuie să știe nimic despre elementele de design sau despre cum va fi redat. Se obține un rezultat care vă permite să schimbați prezentarea datelor, modul în care sunt afișate, fără a atinge Modelul în sine.

Modelul are următoarele caracteristici:

• Modelul este logica de afaceri a aplicației;
• Modelul are cunoștințe despre sine și nu știe despre controlere și vederi;
• Pentru unele proiecte, modelul este pur și simplu un strat de date (DAO, bază de date, fișier XML);
• Pentru alte proiecte, modelul este un manager de baze de date, un set de obiecte sau pur și simplu logica aplicației;

Vedere

Responsabilitățile Vizualizării includ afișarea datelor primite de la Model. Cu toate acestea, vederea nu poate influența direct modelul. Putem spune că o vizualizare are acces numai în citire la date.

Reprezentarea are următoarele caracteristici:

• Vederea implementează afișarea datelor care sunt obținute din model în orice mod;
• În unele cazuri, vizualizarea poate avea cod care implementează o anumită logică de afaceri.

Exemple de prezentare: pagină HTML, formular WPF, formular Windows.

Diferențele dintre MVP și MVVM și MVP

Cele mai comune tipuri de model MVC sunt:

• Model-View-Controller
• Model-View-Presenter
• Model-View-View Model

Să luăm în considerare și să comparăm fiecare dintre ele.

Model-View-Presenter

Această abordare vă permite să creați o abstractizare a reprezentării. Pentru a face acest lucru, trebuie să selectați o interfață de vizualizare cu un set specific de proprietăți și metode. Prezentatorul, la rândul său, primește o referință la implementarea interfeței, se abonează la evenimente de prezentare și modifică modelul la cerere.

Semne ale unui prezentator:

• Vizualizarea interacționează direct cu prezentatorul apelând funcții sau evenimente adecvate în instanța prezentatorului;
• Prezentatorul interacționează cu View folosind o interfață specială implementată de View;
• O instanță de prezentator este asociată cu un afișaj.

Implementare:
Fiecare vizualizare trebuie să implementeze interfața corespunzătoare. Interfața de prezentare definește setul de funcții și evenimente necesare pentru a interacționa cu utilizatorul (de exemplu, Eu văd.ShowErrorMessage(șir msg)). Prezentatorul trebuie să aibă o referință la implementarea interfeței corespunzătoare, care este de obicei trecută în constructor.
Logica de prezentare trebuie să aibă o referință la instanța prezentatorului. Toate evenimentele de vizualizare sunt transmise prezentatorului pentru procesare și aproape niciodată nu sunt procesate de logica prezentării (inclusiv crearea altor vizualizări).

Exemplu de utilizare: Formulare Windows.

Model-View-View Model

Această abordare vă permite să asociați elemente de vizualizare cu proprietăți și evenimente ale modelului de vizualizare. Se poate argumenta că fiecare strat al acestui model nu știe despre existența unui alt strat.

Caracteristici ale modelului View:

• Comunicare bidirecțională cu prezentare;
• Un model de vedere este o abstractizare a unei vederi. De obicei înseamnă că proprietățile vizualizării sunt aceleași cu proprietățile vizualizării/modelului
• Modelul View nu are o referință la interfața de vizualizare (IView). Schimbarea stării modelului View modifică automat vizualizarea și invers, deoarece este utilizat mecanismul de legare a datelor (Legături)
• O instanță a unui model de vizualizare este asociată cu o vedere.

Implementare:
Când se utilizează acest model, vizualizarea nu implementează interfața corespunzătoare (IView).
Vederea trebuie să aibă o legătură către sursa de date (DataContex), care în acest caz este modelul View. Elementele de vizualizare sunt legate de proprietățile și evenimentele corespunzătoare ale modelului de vizualizare.
La rândul său, modelul View implementează o interfață specială care este utilizată pentru a actualiza automat elementele de vizualizare. Un exemplu de astfel de interfață în WPF ar fi INotifyPropertyChanged.

Exemplu de utilizare: WPF

Model-View-Controller

Ideea principală a acestui model este că atât controlerul, cât și vizualizarea depind de model, dar modelul nu depinde de aceste două componente.

Caracteristicile controlerului

• Controlerul determină ce vizualizare ar trebui să fie afișată în acest moment;
• Evenimentele de vizualizare pot afecta doar controlerul Controlerul poate afecta modelul și poate defini o altă vizualizare.
• Sunt posibile vizualizări multiple pentru un singur controler;

Implementare:
Controlerul interceptează evenimentul din exterior și, în conformitate cu logica încorporată în acesta, reacționează la acest eveniment schimbând Modelul apelând metoda corespunzătoare. După o modificare, Modelul folosește evenimentul pe care l-a modificat, iar toate evenimentele View abonate la acesta, după ce l-au primit, apelează la Model pentru date actualizate, după care sunt afișate.

Exemplu de utilizare: MVC ASP.NET

rezumat

Implementarea modelelor MVVM și MVP, la prima vedere, pare destul de simplă și similară. Totuși, pentru MVVM legarea vizualizării la modelul de vizualizare se face automat, dar pentru MVP este necesară programarea
MVC pare să aibă mai mult control asupra vederii.

Reguli generale pentru alegerea unui model

MVVM

• Folosit într-o situație în care legarea datelor este posibilă fără a fi necesară introducerea de interfețe speciale de vizualizare (adică nu este nevoie să implementați IView);
• Un exemplu comun este tehnologia WPF.

MVP

• Folosit într-o situație în care legarea datelor nu este posibilă (legarea nu poate fi utilizată);
• Un exemplu comun ar fi utilizarea Windows Forms.

MVC

• Folosit într-o situație în care comunicarea între vizualizare și alte părți ale aplicației nu este posibilă (și nu puteți utiliza MVVM sau MVP);
• Un caz de utilizare comun este ASP.NET MVC.

Concluzie

În concluzie, autorul acestui articol ar dori să sublinieze că respectarea strictă a unui singur model nu este întotdeauna cea mai bună alegere. De exemplu, imaginați-vă că doriți să utilizați MVVM pentru a dezvolta aplicații folosind Windows Forms prin proprietatea Bindings a controalelor. Scopul dvs. este să separați prezentarea de logica de afaceri și de logica care le conectează. Aplicația ar trebui să fie ușor de testat și susținut și de înțeles pentru analiști (la urma urmei, la întrebarea „cum se măsoară performanța unui hard disk” există un singur răspuns corect - în Joules (exemplu abstract Model -> Vizualizări)) .

Vă mulțumesc foarte mult pentru timpul acordat, citiți cu plăcere!

Model-View-Controller (MVC, „Model-View-Controller”, „Model-View-Controller”) este o schemă pentru separarea datelor aplicației, a interfeței cu utilizatorul și a logicii de control în trei componente separate: model, vizualizare și controler - astfel încât modificarea fiecărei componente poate fi efectuată afară în mod independent.

YouTube enciclopedic

• 1 / 5

  Conceptul MVC a fost descris de Trygve Reenskaug în 1978, care a lucrat la centrul de cercetare Xerox PARC pe limbajul de programare Smalltalk. Mai târziu, Steve Burbeck a implementat modelul în Smalltalk-80.

  Ulterior, modelul de design a început să evolueze. De exemplu, a fost introdusă o versiune ierarhică a HMVC; MVA, MVVM.

  După ce Apple a introdus tehnologia WebObjects, implementată în Objective-C, șablonul a început să se popularizeze pe web [ ] .

  Când WebObjects a fost portat în Java, modelul a devenit popular și acolo. Cadrele mai recente precum Spring (octombrie 2002) au încă o implementare MVC [ ] .

  O nouă rundă de popularitate a fost adusă de dezvoltarea cadrelor axate pe implementarea rapidă în limbajele Python și Ruby, Django și, respectiv, Rails [ ] . Începând cu 2017, cadrele cu MVC au ocupat o poziție proeminentă în raport cu alte cadre fără acest model.

  Diferențele în descrierea conceptului șablonului

  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. De exemplu, Erian Vermi în 2004 a descris un exemplu de MVC generalizat.

  În prefața la disertația lui Richard Pawson Naked Objects, Trygve Reenskaug menționează cea mai veche versiune nepublicată a MVC, conform căreia:

  • Modelul se referea la „mintea” utilizatorului;
  • Prin vizualizare ne referim la un editor care permite utilizatorului să vizualizeze și să actualizeze informații;
  • Controlerul era un instrument de conectare între vizualizări și era folosit de utilizator pentru a-și rezolva problemele.

  Scop

  Scopul principal al aplicării acestui concept este separarea logicii de afaceri ( modele) din vizualizarea sa ( reprezentare, tip). 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 simultan în contexte diferite și/sau din perspective diferite. În special, sunt îndeplinite următoarele sarcini:

  1. Catre unul modele poti atasa mai multe specii, fără a afecta implementarea modele. De exemplu, unele date pot fi prezentate simultan ca o foaie de calcul, o histogramă și o diagramă circulară;
  2. Fără a afecta implementarea specii, puteți modifica reacțiile la acțiunile utilizatorului (făcând clic cu mouse-ul pe un buton, introducerea datelor) - pentru a face acest lucru, utilizați doar un alt controlor;
  3. O serie de dezvoltatori se specializează doar în unul dintre domenii: fie dezvoltarea unei interfețe grafice, fie dezvoltarea logicii de afaceri. Prin urmare, este posibil să ne asigurăm că programatorii dezvoltă logica de afaceri ( modele), nu va fi conștient deloc de ce performanţă va fi folosit.

  Concept

  Conceptul MVC vă permite să separați modelul, vizualizarea și controlerul în trei componente separate:

  Model

  Modelul oferă date și metode de lucru cu acestea: interogări la baza de date, verificarea corectitudinii. Modelul este independent de vedere - nu știe cum să vizualizeze datele - iar controlorul - nu are puncte de interacțiune cu utilizatorul - pur și simplu oferind acces la și manipularea 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ă.

  Un model, datorită independenței sale față de reprezentarea vizuală, poate avea mai multe reprezentări diferite pentru un „model”.

  Performanţă

  Vizualizarea este responsabilă pentru preluarea datelor necesare din model și trimiterea acestora către utilizator. Vizualizarea nu procesează introducerea utilizatorului [ ] .

  O vedere poate influența starea unui model spunându-i modelului despre aceasta.

  Controlor

  Controlerul asigură „comunicații” î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 necesară.

  Funcționalitate și discrepanțe

  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 amplasat atat in controler cat si in model. În acest din urmă caz, modelul va conține toate obiectele de afaceri cu toate datele și funcțiile.

  Unele cadre definesc strict unde ar trebui să fie localizată logica de afaceri, altele nu au astfel de reguli.

  De asemenea, nu este specificat unde ar trebui să fie localizată verificarea intrării utilizatorului. Validarea simplă poate apărea chiar și într-o vizualizare, dar sunt mai frecvente într-un controler sau model.

  De asemenea, internaționalizarea și formatarea datelor nu au linii directoare clare privind locația.

  Modificări condiționate

  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), principalele sunt „observator”, „strategie”, „linker”:

  Cea mai tipică implementare este în care vederea este separată de model prin stabilirea unui protocol de interacțiune între ele folosind „aparatul de evenimente” (notație "evenimente" anumite situații care apar în timpul execuției programului - și trimiterea de notificări despre acestea către toți cei care s-au abonat pentru a primi): cu fiecare modificare specială a datelor interne din model (notat ca „eveniment”), notifică acele opinii care depinde de asta despre asta, care sunt abonați pentru a primi o astfel de alertă - și vizualizarea este actualizată. Așa se folosește modelul „observator”;

  La procesarea reacției utilizatorului, vizualizarea selectează, în funcție de reacție, cea dorită controlor, care va oferi una sau alta conexiune cu modelul. Acest lucru se face folosind modelul „strategie” sau poate fi modificat folosind modelul „comandă”;

  Pentru a permite manipularea uniformă a subobiectelor de tip ierarhic complex, poate fi utilizat ș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 implicit de controler pentru vizualizarea corespunzătoare.

  Cele mai frecvente greșeli

  Programatorii începători interpretează foarte des modelul arhitectural MVC ca un model MVC pasiv: modelul acționează exclusiv ca un set de funcții pentru accesarea datelor, iar controlerul conține logica de afaceri. Drept urmare, codul modelului este de fapt un mijloc de obținere a datelor din DBMS, iar controlerul este un modul tipic plin de logica de afaceri (vezi „scriptul” în terminologia de programare web). Ca urmare a acestei înțelegeri, dezvoltatorii MVC au început să scrie cod pe care Pádraic Brady (cunoscut în comunitatea Zend Framework) l-a caracterizat drept „Fat Stupid Ugly Controllers”:

  TTUK-ul mediu a primit date din baza de date (folosind stratul de abstractizare a bazei de date, pretinzând că este un model) sau a manipulat, verificat, înregistrat și, de asemenea, a transmis date către View. 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.

  Dar programarea orientată pe obiect folosește un model MVC activ, în care modelul nu este doar o colecție de coduri de acces la date și

  Ce este MVC?

  Deci, MVC este despre interfața cu utilizatorul (UI). Nu neapărat grafic, controlul vocal este de asemenea bun. Să nu uităm că un program poate să nu aibă o interfață cu utilizatorul, poate să aibă o interfață de programare a aplicațiilor (API) sau să nu aibă deloc și să fie totuși util.

  Dar dacă avem un utilizator, atunci trebuie să existe o interfață cu utilizatorul. Ce este o interfață? Aceasta este granița contiguă dintre două sisteme. În cazul nostru: pe de o parte - programul, pe de altă parte - utilizatorul. Aici sunt ei.

  Programul este complet abstract, orice cod subiect. Poate face ceva util, iar utilizatorul are nevoi care pot fi satisfăcute cu ajutorul acestui program. Apoi apar bucăți de logică care „știu” cum, folosind acest program, să facă direct ceea ce dorește utilizatorul. Piesele nu sunt logice specifice subiectului în program. Ele sunt mai relevante pentru utilizator cu nevoile sale specifice și sunt combinații de apeluri și apeluri către program.

  Cazuri de utilizare

  De exemplu, imaginați-vă un terminal pentru tranzacționare pe o bursă. Utilizatorul terminalului depune o cerere în care indică că dorește să cumpere 20 de acțiuni ale companiei Svetly Put la un preț de 1.500 de ruble per acțiune. De asemenea, indică faptul că aplicația este valabilă timp de patru ore și din care dintre conturile sale vor fi debitați banii dacă tranzacția este reușită.

  Un număr tangibil de atribute. Trece ceva timp și își dă seama că nu va putea cumpăra la acest preț și este gata să ridice prețul la 1.550 de ruble, lăsând toate celelalte valori. Apoi selectează această aplicație, dă clic pe butonul „modifică”, indică noul preț, da. Este confortabil.

  Dar la schimb nu puteți schimba o comandă în domeniul subiectului nu există un astfel de concept. O cerere poate fi depusă și anulată doar. Pentru a oferi utilizatorului posibilitatea de a schimba o comandă cu un singur clic, trebuie să vă amintiți valorile vechi, să eliminați comanda, să-i lăsați să editeze ceea ce și-a amintit și să plasați o nouă comandă. O astfel de combinație. Dar pentru utilizator pare o acțiune simplă: schimbarea aplicației. Acesta se numește un caz de utilizare.

  Să completăm diagrama noastră cu spațiu pentru cazuri de utilizare.

  

  De asemenea, utilizatorului ar trebui să i se ofere posibilitatea de a extrage aceste cazuri de utilizare și de a obține rezultate. Acestea pot fi butoane și alte elemente grafice de intrare/ieșire, gesturi, recunoaștere și sinteză a vorbirii. Orice opțiune pentru schimbul de date și comenzi. Voila:

  

  Utilizatorul trage unul dintre cazurile de utilizare, care, la rândul său, manipulează programul. Programul publică rezultatul sau modifică starea acestuia.

  Deci unde este MVC oricum?

  Tot ce rămâne este să dai nume familiare componentelor rezultate.

  

  Când modelul publică modificări, nu-i pasă de cine, nu știe nimic despre View. În loc de sau împreună cu View, poate exista un alt subsistem la celălalt capăt.

  Acum câteva detalii.

  Era o versiune clasică a MVC - Active Model. De asemenea, se întâmplă ca modelul să nu anunțe despre modificări. Apoi, controlorul își asumă această responsabilitate. Știe ce manipulări efectuează asupra modelului și, evident, știe ce schimbări pot urma în starea modelului. Acesta este modelul pasiv.

  Și un moment. Împărțirea codului în subiect și non-subiect este arbitrară și depinde de cât de pedant dorim să modelăm domeniul subiectului. Uneori este o decizie rațională să includeți un fel de caz de utilizare în model. Poate că acest lucru va reduce cantitatea de cod în general și o va simplifica.

  Mulțumim abonatului nostru Stanislav Ilyichev pentru material

  Model Model-View-Controller (MVC), descoperit la sfârșitul anilor 1970, este un model de proiectare a arhitecturii software al cărui scop principal este separarea funcțiilor datelor de prezentarea datelor. Teoretic, o aplicație MVC bine concepută va permite dezvoltatorilor front-end și back-end să nu interfereze cu domeniile de responsabilitate ale celuilalt în timpul muncii lor, adică dezvoltatorul front-end nu va trebui să știe nimic despre „bucătărie” a colegului său de back-end și invers.

  Deși MVC a fost conceput inițial pentru dezvoltarea aplicațiilor desktop, a fost adaptat pentru sarcini moderne și este extrem de popular în rândul dezvoltatorilor web, deoarece face posibilă crearea unui cod mai curat și mai reutilizabil prin separarea responsabilităților. Modelul MVC are ca rezultat sisteme curate, modulare, care permit dezvoltatorilor să facă modificări la codul existent foarte rapid.

  În acest articol, ne vom uita la principiile de bază ale MVC, începând cu definirea unui model și continuând cu aplicarea acestuia într-un mic exemplu. Acest articol va fi util în primul rând celor care nu au întâlnit niciodată acest tipar în viață și, poate, de asemenea, celor care doresc să-și perfecționeze cunoștințele despre MVC.

  Înțelegerea MVC

  După cum am menționat deja, numele modelului provine dintr-o abreviere a trei cuvinte: Model (model), VedereȘi Controlor. Pe scurt, principiul de funcționare al modelului poate fi ilustrat cu o diagramă (poate fi găsită pe Wikipedia):

  

  Această diagramă arată clar fluxul unidirecțional de informații în model și, de asemenea, descrie rolurile fiecărei componente.

  Model

  Modelul este folosit pentru a accesa și manipula date. În cele mai multe cazuri, modelul este ceea ce este folosit pentru a accesa depozitul de date (cum ar fi o bază de date). Modelul oferă o interfață pentru căutarea datelor, crearea, modificarea și ștergerea lor din stocare. În contextul modelului MVC, modelul este mediatorul între vedere și controler.

  O caracteristică extrem de importantă a unui model este că, din punct de vedere tehnic, nu cunoaște ceea ce se întâmplă cu datele din controlor și vizualizare. Modelul nu trebuie să facă sau să aștepte niciodată solicitări către/de la alte componente ale modelului.

  Cu toate acestea, amintiți-vă întotdeauna că modelul nu este doar o poartă către o bază de date sau alt sistem care nu face altceva decât să transfere date înainte și înapoi. Un model este ca o poartă către date. Modelul este în majoritatea cazurilor cea mai complexă parte a sistemului, parțial datorită faptului că modelul în sine este veriga de legătură pentru toate celelalte părți.

  Performanţă

  Vizualizarea este locul în care datele primite de la model sunt afișate în forma dorită. În aplicațiile web tradiționale dezvoltate folosind modelul MVC, vizualizarea este partea din sistem în care este generat codul HTML. Vizualizarea este, de asemenea, responsabilă pentru primirea acțiunilor de la utilizator pentru a le trimite controlorului. De exemplu, o vizualizare redă un buton în interfața de utilizare și, atunci când este făcută clic, invocă acțiunea controlerului corespunzătoare.

  Există unele concepții greșite cu privire la scopul unei vizualizări, în special în rândul dezvoltatorilor web care abia încep să-și construiască aplicațiile folosind MVC. Una dintre regulile cele mai des încălcate este aceea vederea nu ar trebui să comunice în niciun fel cu modelul, si tot datele primite de vizualizare ar trebui să provină numai de la operator. În practică, dezvoltatorii ignoră adesea acest concept, care se află la baza modelului MVC. Articolul lui Fabio Cevasco ilustrează această abordare confuză a MVC folosind CakePHP, unul dintre multele cadre MVC non-standard:

  Este extrem de important să înțelegeți că, pentru a obține o arhitectură MVC adecvată, nu ar trebui să existe interacțiuni directe între vederi și modele. Toată logica pentru schimbul de date între ele trebuie implementată în controlere.

  În plus, există o concepție greșită comună că o vizualizare este doar un fișier șablon. După cum a menționat Tom Butler, această concepție greșită este uriașă datorită faptului că mulți dezvoltatori înțeleg greșit structura MVC de la bun început, după care încep să reverse această „cunoaștere” mai mult în masele de dezvoltatori începători. În realitate, o vedere este mult mai mult decât un șablon, dar multe cadre construite pe deasupra modelului MVC au distorsionat atât de mult conceptul de vedere încât nimănui nu-i pasă dacă aplicațiile lor sunt corecte în ceea ce privește modelul MVC.

  Un alt punct important este că vizualizarea nu funcționează niciodată cu date „pure” de la controler, adică controlerul nu funcționează niciodată cu vizualizarea fără a ocoli modelul. În timpul interacțiunii dintre controler și vizualizare, modelul ar trebui să fie întotdeauna între ele.

  Controlor

  Controlerul este ultima parte a pachetului MVC. Sarcina controlorului este să primească date de la utilizator și să manipuleze modelul. Controlerul și numai acesta este partea sistemului care interacționează cu utilizatorul.

  Pe scurt, un controler poate fi descris ca un colector de informații care le transmite modelului pentru procesare și stocare. Nu ar trebui să facă nimic cu datele, ci doar să le poată primi de la utilizator. Controlerul este asociat cu o vedere și un model, organizând astfel un flux unidirecțional de date, controlându-l în fiecare etapă.

  Este foarte important să ne amintim că controlerul își începe activitatea doar ca urmare a interacțiunii utilizatorului cu vizualizarea, care apelează funcția de controler corespunzătoare. Cea mai frecventă greșeală în rândul dezvoltatorilor este de a vedea controlerul ca pur și simplu o poartă de acces între vizualizare și model. Ca urmare, controlerul este dotat cu acele funcții care ar trebui să fie efectuate de vizualizare (apropo, de aici vine ideea că o vizualizare este doar un fișier șablon). În plus, mulți oameni aruncă complet toată logica de procesare a datelor, uitând de ce este destinat modelul în modelul MVC.

  MVC în PHP

  Vă sugerez să încercați să implementați cele de mai sus într-o aplicație mică. Să începem prin a crea clasele model, vizualizare și controler:

  șir = „MVC + PHP = Minunat!”; ) )controler = $controller; $acest->

  " . $this->model->string ."

  "; } } model = $model; ) )

  Clasele principale sunt gata. Acum să le conectăm împreună și să rulăm aplicația noastră:

  ieșire();

  După cum puteți vedea, controlerul nu are nicio funcționalitate, deoarece utilizatorul nu interacționează cu aplicația în niciun fel. Toate funcționalitățile sunt plasate în vizualizare, deoarece aplicația noastră este destinată exclusiv pentru afișarea datelor.

  Să extindem puțin aplicația adăugând ceva interactivitate pentru a vedea cum funcționează controlerul:

  șir = „MVC + PHP = Minunat, dați clic aici!”; ) )controler = $controller; $acest->model = $model; ) funcția publică output() ( return "

  model->șir . "

  "; } } model = $model; ) funcția publică făcută clic () ($this->model->string = „Date actualizate, mulțumită MVC și PHP!”) )

  Și, în sfârșit, să modernizăm ușor codul de conectare:

  ($_GET[„acțiune”])(); ) echo $view->output();

  Rezultate

  În acest scurt articol, ne-am uitat la conceptele de bază ale modelului de design MVC și am dezvoltat o aplicație simplă bazată pe acesta, deși bineînțeles că suntem încă foarte departe de a-l folosi în viața reală. În articolul următor, vom analiza principalele dificultăți pe care le veți întâmpina dacă vă implicați mai mult în construirea unei arhitecturi de aplicație bazată pe modelul MVC. Rămâneţi aproape!