Share
Model-View-Controller (MVC) este probabil unul dintre cele mai cotate modele din lumea programării web din ultimii ani. Oricine lucrează în prezent în orice legătură cu dezvoltarea de aplicații web va auzi sau citi acronimul de sute de ori. Astăzi vom clarifica ce înseamnă MVC și de ce a devenit atât de popular.
MVC nu este un model de design, este un model arhitectural care descrie o modalitate de a structura aplicația noastră și responsabilitățile și interacțiunile pentru fiecare parte din structura respectivă.
A fost descris pentru prima dată în 1979 și, evident, contextul a fost puțin diferit. Conceptul de aplicație web nu a existat. Tim Berners Lee a semănat semințele de la World Wide Web la începutul anilor nouăzeci și a schimbat lumea pentru totdeauna. Modelul pe care îl folosim astăzi pentru dezvoltarea web este o adaptare a modelului original.
Popularizarea sălbatică a acestei structuri pentru aplicațiile web se datorează includerii sale în două cadre de dezvoltare care au devenit extrem de populare: Struts și Ruby on Rails. Aceste două medii au marcat calea pentru sutele de cadre create ulterior.
Ideea modelului arhitectural Model-View-Controller este simplă: trebuie să avem următoarele responsabilități clar separate în aplicația noastră:
Aplicația este împărțită în aceste trei componente principale, fiecare dintre ele însărcinând cu sarcini diferite. Să vedem o explicație detaliată și un exemplu.
Controlor gestionează solicitările utilizatorilor (primite ca cereri HTTP GET sau POST când utilizatorul face clic pe elementele GUI pentru a efectua acțiuni). Funcția sa principală este de a apela și coordona resursele / obiectele necesare pentru a efectua acțiunea utilizatorului. De regulă, controlorul va apela modelul corespunzător pentru sarcină și apoi va selecta vizualizarea corespunzătoare.
Model sunt datele și regulile aplicabile acestor date, care reprezintă concepte pe care aplicația le administrează. În orice sistem software, totul este modelat ca date pe care le manipulăm într-un anumit mod. Ce este un utilizator, un mesaj sau o carte pentru o aplicație? Doar datele care trebuie tratate conform regulilor specifice (data nu poate fi în viitor, e-mailul trebuie să aibă un format specific, numele nu poate fi mai mare de x caractere lungime etc.).
Modelul oferă controlorului o reprezentare a datelor indiferent de utilizatorul solicitat (un mesaj, o listă de cărți, un album foto etc.). Acest model de date va fi același indiferent de modul în care este posibil să îl prezentăm utilizatorului, de aceea putem alege orice vizualizare disponibilă pentru ao face.
Modelul conține cea mai importantă parte a logicii noastre de aplicații, logica care se aplică problemei cu care ne confruntăm (un forum, un magazin, o bancă etc.). Controlorul conține o logică mai organizatorică internă pentru aplicația în sine (mai mult ca menaj).
Vedere oferă moduri diferite de prezentare a datelor primite de la model. Acestea pot fi șabloane în care datele respective sunt completate. Pot exista mai multe viziuni diferite, iar controlorul trebuie să decidă care dintre acestea să fie utilizat.
O aplicație web este, de obicei, compusă dintr-un set de controale, modele și vederi. Controlorul poate fi structurat ca un controler principal care primește toate cererile și cheamă controale specifice care gestionează acțiunile pentru fiecare caz.
Să presupunem că dezvoltăm un magazin online de cărți. Utilizatorul poate efectua acțiuni cum ar fi: vizualizarea cărților, înregistrarea, cumpărarea, adăugarea de elemente la comanda curentă, crearea sau ștergerea cărților (dacă acesta este administrator, etc.). Să vedem ce se întâmplă când utilizatorul face clic pe fantezie pentru a vedea titlurile pe care le avem la dispoziție.
Vom avea un controler special care să se ocupe de toate acțiunile legate de cărți (vizualizați, editați, creați, etc.). Să numim book_controller.php pentru acest exemplu. De asemenea, vom avea un model, de exemplu book_model.php, care gestionează date și logică referitoare la articolele din magazin. În cele din urmă, vom avea o serie de opinii pentru a prezenta, de exemplu, o listă de cărți, o pagină pentru editarea cărților etc..
Următoarea figură arată modul în care utilizatorul solicită să vizualizeze lista cărților fantastice este tratată:
Controlorul (books_controller.php) primește solicitarea utilizatorului [1] ca o solicitare HTTP GET sau POST (putem avea și un controler central, de exemplu, index.php îl primește și apoi sună la books_controller.php).
Controlorul examinează cererea și parametrii și solicită modelul (book_model.php) cer el pentru a reveni lista de cărți de fantezie disponibile [2].
Modelul este responsabil pentru obținerea informațiilor din baza de date (sau oriunde este stocat) [3], aplică filtre sau logică dacă este necesar și returnează datele care reprezintă lista cărților [4].
Controlorul va utiliza vizualizarea corespunzătoare [5] pentru a prezenta aceste date utilizatorului [6-7]. Dacă cererea a venit de pe un telefon mobil, va fi utilizată o vizualizare pentru telefoanele mobile, dacă utilizatorul are un anumit skin selectat, va fi aleasă vizualizarea corespunzătoare și așa mai departe.
Cel mai evident avantaj pe care îl câștigăm folosind MVC este o separare clară a prezentării (interfața cu utilizatorul) și logica aplicației.
Sprijinul pentru diferite tipuri de utilizatori care folosesc diferite tipuri de dispozitive este o problemă obișnuită în aceste zile. Interfața prezentată trebuie să fie diferită dacă cererea a venit de la un computer desktop sau de la un telefon mobil. Modelul returnează exact aceleași date, singura diferență fiind aceea că controlerul va alege o viziune diferită pentru a le face (ne putem gândi la un alt șablon).
În afară de izolarea vederii din logica de afaceri, separarea M-V-C reduce complexitatea atunci când proiectează aplicații mari. Codul este mult mai structurat și, prin urmare, mai ușor de întreținut, testa și reutilizat.
Când utilizați un cadru, structura de bază pentru MVC este deja pregătită și trebuie doar să extindeți această structură, plasându-vă fișierele în directorul corespunzător, pentru a se conforma modelului Model-View-Controller. De asemenea, veți obține o mulțime de funcții deja scrise și testate temeinic.
Luați cakePHP ca exemplu de cadru MVC. Odată ce l-ați instalat, veți vedea trei directoare principale:
aplicaţia dosarul este locul unde plasați fișierele. Este locul dvs. pentru a vă dezvolta partea din aplicație.
tort dosarul este acolo unde cakePHP are fișierele sale și unde au dezvoltat rolul lor (funcționalitatea principală a cadrului).
vânzătorii dosarul este pentru biblioteci PHP de la terțe părți, dacă este necesar.
Locul de lucru (directorul de aplicații) are următoarea structură:
Acum trebuie să puneți controlorii în controlere director, modelele dvs. în modele directorul și opiniile dvs. în ... vizualizari director!
Odată ce vă obișnuiți cu cadrul dvs., veți putea afla unde să căutați aproape orice cod de cod pe care trebuie să-l modificați sau să-l creați. Numai această organizație face ca mentenabilitatea să fie mult mai ușoară.
Din moment ce acest tutorial nu are scopul de a vă arăta cum să creați o aplicație folosind cakePHP, vom folosi doar pentru a afișa un exemplu de cod pentru componentele modelului, vizualizării și a controlorului și vom comenta despre beneficiile utilizării unui cadru MVC. Codul este simplificat și nu este potrivit pentru aplicații reale.
Amintiți-vă că am avut un magazin de cărți și un utilizator curios care dorește să vadă lista completă de cărți din fantezie categorie. Am spus că operatorul va fi cel care primește cererea și va coordona acțiunile necesare.
Deci, când utilizatorul face clic, browserul va solicita această adresă URL:
www.ourstore.com/books/list/fantasy
CakePHP îi place să formateze URL-uri în formularul / controller / action / param1 / param2, unde acțiune este funcția de apel în cadrul controlerului. În vechiul format clasic de url ar fi:
www.ourstore.com/books_controller.php?action=list&category=fantasy
Cu ajutorul cadrului cakePHP, controlorul nostru va arăta cam așa:
Accentsconagua
set ('cărți', $ this-> Book-> findAllByCategory ($ category)); funcția add () ... funcția delete () ... ...?> Simplu, nu-i așa? Acest controler va fi salvat ca books_controller.php și plasat în / app / controllers. Acesta conține funcția de listă pentru a efectua acțiunea în exemplul nostru, dar și alte funcții pentru a efectua alte acțiuni legate de carte (adăugați o carte nouă, ștergeți o carte nouă etc.).
Cadrul oferă multe lucruri pentru noi și este necesară o singură linie pentru a lista cărțile. Avem clase de bază cu comportamentul controlerului de bază deja definit, așa că moștenim de la ei (AppController care moștenește de la Controller).
Tot ce are de facut in actiunea listei este sa apeleze modelul pentru a obtine datele si apoi sa aleaga o vizualizare pentru a le prezenta utilizatorului. Să explicăm cum se face acest lucru.
this-> Book este modelul nostru, și această parte:
$ This-> cartea-> findAllByCategory (categoria $)
spune modelul să returneze lista de cărți din categoria selectată (vom vedea mai târziu modelul).
a stabilit metoda în linie:
$ this-> set ('cărți', $ this-> Book-> findAllByCategory ($ category)); Este modul în care controlerul transmite datele în vizualizare. Setează cărți variabilă la datele returnate de model și îl face accesibil vizualizării.
Acum trebuie doar să redați vizualizarea, dar acest lucru se va face automat de către cakePHP dacă dorim vizualizarea implicită. Dacă avem nevoie de altă viziune, trebuie doar să o numim în mod explicit folosind face metodă.
Modelul este chiar mai simplu:
De ce gol? Deoarece moșteneste dintr-o clasă de bază care oferă funcționalitatea necesară și am urmat convențiile de nume CakePHP pentru a permite cadrului să facă alte sarcini în mod automat. De exemplu, cakePHP știe, pe baza numelor, că acest model este utilizat în BooksController și că va accesa un tabel de baze de date numit cărți.
Cu această declarație avem doar un model de carte capabil să citească, să șterge sau să salveze date din baza de date
Codul va fi salvat ca book.php și plasat în / app / models.
Tot ce trebuie să facem acum este crearea unei viziuni (cel puțin una) pentru acțiunea pe listă. Vizualizarea va avea codul HTML și câteva linii PHP (cât mai puține posibil) pentru a trece prin matricea cărților furnizate de model.
| Titlu | Autor | Preț |
|---|---|---|
După cum vedem, vizualizarea nu produce o pagină completă, doar un fragment HTML (un tabel în acest caz). Acest lucru se datorează faptului că CakePHP oferă o altă modalitate de a defini aspectul paginii, iar vizualizările sunt inserate în acel aspect. Cadrul oferă, de asemenea, câteva obiecte helper pentru a face sarcina obișnuită ușoară atunci când creați aceste fragmente HTML (inserați formulare, linkuri, Ajax sau JavaScript).
Facem această vizualizare implicită salvând-o ca list.ctp (lista este numele acțiunii și ctp înseamnă șablonul tort) și plasându-l în / app / views / books (în interiorul cărților, deoarece acestea sunt vizionări pentru acțiunile controlorilor de cărți).
Și acest lucru completează cele trei componente cu ajutorul cadrului CakePHP!
Am învățat astăzi probabil cel mai des utilizat model arhitectural astăzi. Trebuie să fim conștienți, însă, că atunci când vorbim despre modele în lumea programării, vorbim despre cadre flexibile, care să fie adaptate la problema particulară de care dispunem. Vom găsi implementări care introduc variații ale structurii pe care am văzut-o, dar important este că, în final, modelul ne ajută să obținem o diviziune clară între responsabilități și o mai bună întreținere, reutilizarea codului și testarea.
De asemenea, am văzut avantajele utilizării unui cadru MVC care ne oferă un schelet MVC de bază și o mulțime de funcționalități, îmbunătățind productivitatea și facilitând procesul de dezvoltare. Vă mulțumim pentru lectură!
