În acest articol vom scrie un „schelet” al proiectului nostru. Prin cuvântul „cadru” mă refer la un cod de lucru care se va baza pe abordarea MVC, adică va avea o împărțire clară a logicii în controlere, acțiuni, șabloane (vizualizări) și modele.

Și să începem, așa cum am scris deja în articolul anterior, modelul MVC implică un singur punct de intrare - index.php, toate cererile vor trece prin acest script, toată logica proiectului va funcționa prin el. Pentru a implementa această abordare, trebuie să configurați serverul, se presupune că site-ul rulează pe un server apache, așa că trebuie doar să creăm un fișier .htaccess, în care vom specifica regulile de rutare URL. Pe lângă definirea punctului de intrare, rutarea vă permite să creați CNC (URL-uri care pot fi citite de om). Adică, după setările corecte, adresele paginilor vor arăta ca acest site.ru/article/new.
Mai întâi, să creăm un .htaccess care va redirecționa procesarea tuturor paginilor către scriptul index.php. Codul arată astfel:

RewriteEngine pe RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule ^ (. *) $ Index.php? Ruta = 1 $

Fișierul .htaccess trebuie să fie localizat în folderul rădăcină al site-ului, iar imediat este necesar să se creeze scriptul index.php, care este punctul de intrare. Să punem o linie în index.php pentru a testa dacă redirecționarea funcționează:

Echo „test”;

Acum puteți verifica dacă redirecționarea funcționează, introduceți orice adresă și vedeți ce se întâmplă: test-mvc.web / sdf / sdf / sau test-mvc.web / sdf / sdf / 2342 / nu contează, în orice caz, „Test”. Dacă ați văzut această inscripție, înseamnă că am reușit.
Să continuăm, pentru comoditate, să creăm un fișier config.php în rădăcina site-ului, în care vom seta diverse constante care ușurează personalizarea site-ului. Acestea pot fi căi diferite către scripturi, acces la baza de date și așa mai departe. Acum, în configurație, să setăm următoarele:

// Setează constante: define („DS”, DIRECTORY_SEPARATOR); // separator pentru căile fișierelor $ sitePath = realpath (dirname (__ FILE__). DS); definiți ("SITE_PATH", $ sitePath); // calea către folderul rădăcină al site-ului // pentru a se conecta la definirea bazei de date ("DB_USER", "root"); definiți ("DB_PASS", ""); define („DB_HOST”, „localhost”); define („DB_NAME”, „blog_mvc”);

Pentru ca constantele și alte date de configurare să fie folosite pe tot parcursul proiectului, este necesar să includeți scriptul config.php în fișierul index.php.
Pe lângă conectarea fișierului cu setări, în index.php trebuie să creați o conexiune la baza de date, să conectați un script cu nucleul site-ului și să porniți un router în care va avea loc rutarea.
Acum, în ordine, crearea unei conexiuni la baza de date va fi în index.php, astfel încât conexiunea să fie deschisă o singură dată. După ce am deschis conexiunea o dată, o putem folosi în toate controlerele și modelele, dar mai multe despre asta mai târziu. Deocamdată, să creăm doar o conexiune la bază. Pentru a lucra cu baza de date, am decis să folosesc PDO. Puteți citi mai multe despre DOP.
Vom plasa miezul site-ului în folderul de bază și vom numi scriptul core.php, aici vom scrie o funcție care se va conecta singură, clasele sunt necesare pentru lucru. O astfel de funcție va facilita și simplifica foarte mult munca noastră cu controlere, modele etc. Pentru că, privind în viitor, voi spune că fiecare controler și fiecare model va fi o clasă separată.
Pe lângă autoconectarea claselor, vom adăuga un depozit (registru) la nucleul creării unui depozit, în care vom stoca toate obiectele și variabilele necesare care pot fi utile oriunde în proiect.
De asemenea, conectăm routerul în fișierul index, acesta va analiza adresa URL și va conecta controlerul și acțiunea necesare. Am scris ce este un controler în articolul precedent, dar am sărit în mod intenționat informațiile despre acțiune, fără a fi supraîncărcat cu informații inutile. Deci, ce este acțiunea?
Un controler este o clasă care conține diverse metode, cu abordarea MVC, fiecare metodă va fi o acțiune. Adică, o acțiune este o metodă de clasă care va procesa datele și le va transmite vizualizării (șablonului). Poate că nu este încă pe deplin clar, dar după exemplu totul va cădea la locul lor.
În acest stadiu, teoria este suficientă, să trecem la practică. Voi da codul fișierelor, a căror activitate am descris-o mai sus.
Cod script index.php:

// permite afișarea tuturor erorilor error_reporting (E_ALL); // include config include ("/config.php"); // Conectați-vă la baza de date $ dbObject = PDO nou ("mysql: host =". DB_HOST. "; Dbname =". DB_NAME, DB_USER, DB_PASS); // include nucleul site-ului include (SITE_PATH. DS. „core”. DS. „core.php”); // Încărcare router $ router = router nou (registru $); // scrie datele în registry $ registry-> set ("router", $ router); // setați calea către folderul controlere. $ router-> setPath (SITE_PATH. „controlere”); // porniți routerul $ router-> start ();

Scriptul Core.php:

// Încărcați clasele din funcțiune __autoload ($ className) ($ filename = strtolower ($ className). ".Php"; // definiți clasa și găsiți calea pentru ea $ expArr = explode ("_", $ className) ); if (gol ($ expArr) SAU $ expArr == "Baza") ($ folder = "clase";) else (comutați (strtolower ($ expArr)) (case "controller": $ folder = "controlere"); break ; caz "model": $ folder = "modele"; pauză; implicit: $ folder = "clase"; break;)) // calea către clasa $ fișier = SITE_PATH. $ folder. DS. $ nume fișier; // verificați pentru fișier de disponibilitate if (fișier_există (fișier $) == false) (return false;) // include fișierul cu clasa include (fișier $);) // pornește registrul (stocare) $ registry = Registrul nou;

Clasa de depozit Registry.php va fi localizată în folderul / classes /

// Clasa de stocare Class Registry (privat $ vars = array (); // scrie setul de funcții de date ($ cheie, $ var) (dacă (isset ($ this-> vars [$ cheie]) == adevărat) (aruncă nou) Excepție ("Nu se poate seta var` ". $ Key." `. Deja setat.");) $ This-> vars [$ key] = $ var; return true;) // obțineți funcția de date get ($ key) (if (isset ($ this-> vars [$ cheie])) == false) (return null;) return $ this-> vars [$ cheie];) // elimină funcția de date remove ($ var) (unset ($ asta-> vars [cheia $]);))

Codul pentru fișierul router.php, care se află în folderul / classes /

// clasa routerului Class Router (registru $ privat; cale $ privată; args $ private = matrice (); // obține funcția de stocare __construct (registru $) ($ this-> registry = $ registry;) // setează calea către folderul cu funcția controlere setPath ($ cale) ($ cale = trim ($ cale, "/ \\"); $ cale. = DS; // dacă calea nu există, semnalați-o dacă (is_dir ( $ cale) == false ) (aruncă o nouă excepție ("Calea controlerului nevalidă:` ". $ cale." '");) $ this-> path = $ cale;) // definiția controlerului și acțiunii din funcția privată URL getController (& $ fișier, & $ controler, & $ acțiune, & $ args) ($ ruta = (gol ($ _ GET [„rută”]))? „”: $ _GET [„rută”]; nesetat ($ _ GET [„rută”]); if (goală ($ ruta)) ($ ruta = „index”;) // Obține părți din adresa URL $ ruta = trim ($ ruta, "/ \\"); $ părți = explode ("/", $ ruta); // Găsiți controlerul $ cmd_path = $ this-> path; foreach ($ părți ca $ parte) ($ fullpath = $ cmd_path. $ Part; // Verificați dacă folderul există if (is_dir ($ calea completă)) ($ cmd_path. = $ parte DS; array_shift ($ părți); continua; ) // Găsiți fișierul dacă (is_file ($ fullpath. ".Php")) ($ controller = $ part; array_shift ($ parts); break;)) // dacă adresa URL nu specifică un controler, atunci utilizați index implicit if (empty ($ controller)) ($ controller = "index";) // Obține acțiunea $ action = array_shift ($ parts); if (gol (goală ($ acțiune)) ($ acțiune = „index”;) $ fișier = $ cmd_path. controler $. „.php”; $ args = $ părți; ) function start () (// Analizați calea $ this-> getController ($ fișier, $ controller, $ acțiune, $ args); // Verificați dacă fișierul există, în caz contrar 404 if (is_redable ($fișier) == false ) (die ("404 Not Found");) // Includeți fișierul include (fișier $); // Creați o instanță a controlerului $ class = "Controller_". $ Controller; $ controller = noua $ clasă ($ this -> registry); // Dacă acțiunea nu există - 404 if (is_callable (array ($ controller, $ action)) == false) (die ("404 Not Found");) // Execută acțiunea $ controler -> $ action ();))

Acum trebuie să creăm foldere pentru stocarea controlerelor, șabloanelor și modelelor - la rădăcină vom crea trei foldere controlere, vizualizări și modele. Și să creăm câteva fișiere de testare /controllers/index.php, /views/index/index.php și /models/model_users.php și acum completăm fișierele:
Pentru controler:

// Controller Class Controller_Index Extinde Controller_Base (// template public $ layouts = "first_layouts"; // action function index () ($ model = new Model_Users (); $ userInfo = $ model-> getUser (); $ this-> template-> vars ("userInfo", $ userInfo); $ this-> template-> view ("index");))

Pentru afișare (/views/index/index.php)

Vedere de testare
id:
Nume:

Si modelul:

// model Clasa Model_Users (funcția publică getUser () (return array ("id" => 1, "name" => "test_name");))

După cum probabil ați observat, clasa controlerului moștenește de la clasa părinte Controller_Base. Acest lucru se face pentru a simplifica clasa de controler. Deoarece încă trebuie să conectăm clasa pentru a lucra cu șabloane, conexiunea acesteia este mutată în Controller_Base.
Îi voi da codul, se află în folderul / classes / și se numește controller_base.php:

// clasa controler abstractă Clasa abstractă Controller_Base (registru $ protejat; șablon $ protejat; machete $ protejate; // șablon public $ vars = matrice (); // include șabloane în funcția de constructor __construct (registru $) ($ this-> registry = $ registry; // șabloane $ this-> template = new Template ($ this-> layouts, get_class ($ this));) index al funcției abstracte ();)

Acum tot ce rămâne este să ne ocupăm de șabloane. În clasa abstractă Controller_Base, numim clasa Template și îi transmitem numele șablonului și numele controlerului.
Codul clasei Template, care se află aici / classes / și se numește template.php

// clasă pentru conectarea șabloanelor și transmiterea datelor către șablonul de clasă de afișare (șablon $ privat; controler $ privat; machete $ private; vars $ private = matrice (); funcția __construct (dispoziții $, $nume controler) ($ this-> layouts) = $ layouts; $ arr = explode ("_", $ controllerName); $ this-> controller = strtolower ($ arr);) // setarea variabilelor pentru a afișa funcția vars ($ varname, $ value) (if (isset ( $ this-> vars [$ varname]) == true) (trigger_error ("Nu se poate seta var` ". $ varname." `. Deja setat, și suprascrie nu este permisă.", E_USER_NOTICE); return false;) $ this -> vars [$ varname] = $ value; return true;) // Afișează vizualizarea funcției ($ nume) ($ pathLayout = SITE_PATH. „views”. DS. „layouts”. DS. $ this-> layouts. „. php "; $ contentPage = SITE_PATH." vizualizează ". DS. $ acest-> controler. DS. $ nume." .php "; dacă (fișier_există ($ pathLayout) == false) (trigger_error ("Layout `". $ this-> layouts. "'nu există.", E_USER_NOTICE); return false;) if (fișier_există ($ contentPage) == fals) (trigger_error ("Șablon` ". $ nume. "` nu există. ", E_USER_NOTICE); returnează fals; ) foreach ($ this-> vars as $ key => $ value) ($$ cheie = $ value;) include ($ pathLayout); ))

Dacă ați citit cu atenție codul, probabil v-ați dat seama că pentru afișarea în pagini folosim șablonul first_layouts și vizualizarea index.php (display) - am dat codul acestuia chiar mai sus. Tot ce ne rămâne este să creăm fișierul șablon first_layouts. Plasați-l în folderul /views/layouts/first_layouts.php
Șablonul va conține următorul cod:

antet

subsol

Asta e tot, asta completează crearea „cadrei”. Acum avem cea mai simplă structură bazată pe modelul MVC. În acest articol, nu m-am referit la lucrul cu baza de date, doar am menționat-o în treacăt, deoarece articolul era deja lung. Voi descrie lucrul direct cu baza de date în articolul următor.
Așa se încheie articolul, puteți descărca sursele din arhivă.

Model Model-View-Controller (MVC), descoperit la sfârșitul anilor 1970, este un model de proiectare a arhitecturii software care se concentrează pe decuplarea funcțiilor de date de prezentarea lor. În teorie, 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 trebuie să știe nimic despre „bucătărie”. " a colegului său de back-end și invers.

Deși conceput inițial pentru dezvoltarea de aplicații desktop, MVC a fost adaptat pentru nevoile actuale și este extrem de popular în rândul dezvoltatorilor web, deoarece separarea preocupărilor a făcut posibilă crearea unui cod mai clar și reutilizabil. Modelul MVC are ca rezultat sisteme clare, modulare, care permit dezvoltatorilor să facă modificări la codul existent foarte rapid.

În acest articol, vă vom prezenta elementele de bază ale MVC, începând prin definirea unui model și continuând cu un mic exemplu. Acest articol va fi util în primul rând pentru cei care nu au întâlnit niciodată acest tipar în viața lor și, eventual, pentru cei care doresc să-și perfecționeze cunoștințele despre MVC.

Înțelegerea MVC

După cum am menționat deja, numele modelului provine de la prescurtarea a trei cuvinte: Model Vedereși Controlor... Pe scurt, principiul 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, un model este ceea ce este folosit pentru a accesa un depozit de date (cum ar fi o bază de date). Modelul oferă o interfață pentru preluarea, crearea, modificarea și ștergerea datelor din stocare. În contextul modelului MVC, modelul mediază între vedere și controler.

O caracteristică extrem de importantă a modelului este că, din punct de vedere tehnic, nu cunoaște ce se întâmplă cu datele din controlor și din 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ă un model nu este doar o poartă către o bază de date sau alt sistem care nu face altceva decât să transmită date înainte și înapoi. Un model este ca o poartă către date. Modelul este în majoritatea cazurilor cea mai complexă parte a sistemului, în parte pentru că modelul în sine este lipiciul pentru toate celelalte părți.

Reprezentare

Vizualizarea este locul în care datele primite de la model sunt afișate în forma dorită. În aplicațiile web tradiționale dezvoltate cu modelul MVC, o vizualizare este partea din sistem în care este generat 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 cu utilizatorul și, la clic pe el, invocă acțiunea corespunzătoare a controlerului.

Există unele concepții greșite cu privire la scopul vizualizării, î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 trebuie 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 arhitectura MVC corectă, nu ar trebui să existe interacțiuni directe între vederi și modele. Toată logica schimbului de date între ei trebuie implementată în controlori.

În plus, există o concepție greșită comună că o vizualizare este doar un fișier șablon. După cum a remarcat Tom Butler, această concepție greșită are o amploare 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 departe, mase de dezvoltatori începători. În realitate, o vedere este mult mai mult decât un șablon, cu toate acestea, multe cadre construite pe baza modelului MVC au distorsionat atât de mult conceptul de vedere încât nimănui nu-i pasă cât de corecte sunt aplicațiile lor din punctul de vedere al Model MVC.

De asemenea, este important ca vizualizarea să nu funcționeze niciodată cu date „pure” de la controler, adică controlerul nu funcționează niciodată cu vizualizarea ocolind modelul. În procesul de interacțiune dintre controlor și vedere, modelul trebuie să fie întotdeauna între ele.

Controlor

Controlerul este piesa finală a grupului MVC. Sarcina controlorului este să primească date de la utilizator și să manipuleze modelul. Controlerul, și numai el, este partea sistemului care interacționează cu utilizatorul.

Pe scurt, un controler poate fi descris ca un colector de informații care le transferă la un model pentru procesare și stocare. El 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 de date unidirecțional, controlându-l în fiecare etapă.

Este foarte important să ne amintim că controlerul își începe activitatea numai ca urmare a interacțiunii utilizatorului cu vizualizarea, care apelează funcția corespunzătoare a controlerului. Cea mai frecventă greșeală în rândul dezvoltatorilor este să trateze un controler ca pe o poartă de acces între vizualizare și model. Ca urmare, controlerul este dotat cu funcțiile pe care ar trebui să le îndeplinească vizualizarea (apropo, de aici vine ideea că vizualizarea este doar un fișier șablon). În plus, mulți oameni aruncă cu totul 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, View și Controller:

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

". $ 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 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 doar 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!”; ))controller = $ controller; $ asta-> model = $ model; ) funcția publică ieșire () (return "

model-> șir. "

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

În sfârșit, să actualizăm puțin codul de adeziv:

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

Rezultate

În acest scurt articol, am acoperit 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 o folosi în viața reală. În următorul articol, ne vom uita la principalele dificultăți cu care te vei confrunta dacă te concentrezi mai mult pe construirea unei arhitecturi de aplicații bazate pe modelul MVC. Rămâneți aproape!

În acest tutorial, veți învăța cum să construiți un sistem de arhitectură MVC (Model-View-Controller) simplu în PHP 5.1 folosind capabilitățile bibliotecii SPL (Standard PHP Library).

Introducere

Bine ați venit la primul tutorial complet pentru PHP 5. Veți avea nevoie de PHP 5.1 cu SPL-ul instalat, deoarece vom profita de unele dintre cele mai recente caracteristici PHP 5.

În acest tutorial, vă voi arăta cum să construiți un sistem MVC simplu (arhitectura MVC este cel mai comun model de design pentru aplicații web mari). Vă voi ghida prin toți pașii de la început până la sfârșit ai creării unui sistem MVC complet.

Un singur punct de intrare

Unul dintre lucrurile importante despre MVC este un punct de intrare în aplicație în loc de o grămadă de fișiere PHP care fac ceva de genul acesta:

Vom avea un singur fișier care se ocupă de toate cererile. Aceasta înseamnă că nu trebuie să ne îngrijorăm cu privire la conectarea global.php de fiecare dată când trebuie să creăm o pagină nouă. Acest „punct de intrare unic” se va numi index.php și deocamdată va fi:

După cum puteți vedea, acest script încă nu face nimic, dar așteptați un minut.

Pentru a direcționa toate solicitările către pagina de pornire, vom folosi mod_rewrite și vom seta directiva RewriteRule în .htaccess. Să lipim următorul cod în fișierul .htaccess și să-l salvăm în același director ca index.php:

RewriteEngine pe RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule ^ (. *) $ Index.php? Ruta = 1 $

Mai întâi, verificăm dacă fișierul solicitat există folosind directiva RewriteCond, iar dacă nu, atunci redirecționăm cererea către index.php. Această verificare a existenței fișierului este necesară, deoarece în caz contrar index.php va încerca să proceseze toate solicitările către site, inclusiv cererile de imagini. Și pur și simplu nu avem nevoie de asta.

Dacă nu puteți utiliza .htaccess sau mod_rewrite, atunci va trebui să adresați manual toate solicitările către index.php. Cu alte cuvinte, toate linkurile ar trebui să aibă forma „index.php? Route = [request goes here]”. De exemplu, „index.php? Route = chat / index”.

Acum că toate cererile trec prin același punct de intrare, putem începe să scriem scriptul index.php. Primul lucru pe care trebuie să-l facem este să inițializam sistemul. Să creăm directorul includes și în el fișierul startup.php (il vom avea ca fișier de inițializare). Să lipim următorul cod în index.php:

În acest exemplu, declarăm o constantă, aflăm unde sunt fișierele de sistem și, de asemenea, verificăm că versiunea PHP este, ei bine, cel puțin 5.1.

Următorul lucru de făcut este un obiect Registry pentru a stoca valori globale. Acesta va fi transmis la obiecte separate din sistem și folosit pentru a accesa valori globale și fără a fi nevoie de a desemna variabile ca „globale” sau de a accesa tabloul $ GLOBALS. Consultați articolul „Utilizarea valorilor globale în PHP” pentru mai multe informații despre obiectul registry.

Adăugați următorul cod în fișierul startup.php după exemplul anterior:

$ registry = registru nou;

Dacă încercați să porniți sistemul acum, puteți vedea următoarea eroare:

Eroare fatală: clasa „Registry” nu a fost găsită în g: \ Proiecte \ PHP \ conținut \ simplu mvc php5 \ demo \ include \ startup.php pe linia 12

Aceasta, desigur, nu este o mare surpriză pentru noi, deoarece încă nu am scris clasa Registry în sine. Fișierul cu clasa ar putea fi inclus pur și simplu folosind funcția include () (Bandă notă: apropo, include () nu este o astfel de funcție, dar totuși o expresie de limbaj, o structură de control, dacă te uiți la manu), dar haideți Să folosim una dintre noile caracteristici din PHP 5: __autoload ().

Funcția magică __autoload () este folosită pentru a încărca dinamic clasele. Când PHP detectează o clasă inexistentă, mai întâi apelează funcția __autoload () și abia apoi aruncă o eroare. Putem profita de această oportunitate pentru a încărca cursurile din mers.

Lipiți acest cod înainte de codul din exemplul anterior:

// Încărcați clasele din funcțiune __autoload ($ class_name) ($ filename = strtolower ($ class_name). ".Php"; $ fișier = site_path. "Class". DIRSEP. $ Filename; if (file_exists ($ file) = = false) (întoarce false;) include (fișier $);)

Funcția noastră __autoload () ia numele clasei transmis ca argument și verifică dacă un fișier cu un nume similar există în directorul clasei. Dacă nu există niciun fișier, atunci funcția va returna pur și simplu false și va apărea o eroare fatală. Dar dacă fișierul există, acesta va fi încărcat. Acestea. clasa necesară va fi declarată și nu va exista nicio eroare.

Nu am creat încă clasa Registry, așa că eroarea va apărea în continuare. Să trecem la asta.

Crearea clasei Registry

Clasa Registry este folosită pentru a trece valori globale între obiecte individuale. Este de fapt o clasă destul de simplă care trebuie să implementeze câteva metode mici.

Mai întâi, să creăm un director de clase și un fișier registry.php în el. Să lipim următorul cod în registry.php:

Acum avem un „schelet” al clasei Registry și trebuie să-l încărcăm cu metode. Să scriem 2 metode: set () pentru a seta valori și get () pentru a obține valori. De asemenea, puteți scrie o metodă remove () pentru a elimina valori. Să adăugăm aceste metode la clasa Registry:

Set de funcții ($ key, $ var) (dacă (isset ($ this-> vars [$ key]) == true) (aruncă o nouă excepție ("Nu se poate seta var` ". $ Key." `. Deja setat. ");) $ this-> vars [$ cheie] = $ var; return true;) function get ($ key) (if (isset ($ this-> vars [$ key]) == false) (return null; ) returnează $ this-> vars [$ cheie];) function remove ($ var) (unset ($ this-> vars [$ cheie]);)?>

Aceste metode sunt simple, setează, obțin și elimină elemente din matricea $ vars, care este un atribut de clasă. În metoda set (), verificăm și dacă valoarea cu cheia specificată există deja, iar dacă există, atunci aruncăm o excepție. Acest lucru este pentru a evita suprascrierea accidentală a valorilor.

Acum avem o clasă completă de Registry, dar nu ne vom opri asupra asta. Să folosim una dintre caracteristicile bibliotecii SPL: ArrayAccess. SPL (prescurtare de la Standard PHP Library) este o colecție de interfețe și clase concepute pentru a rezolva probleme comune. Una dintre interfețele SPL, ArrayAccess, poate fi utilizată pentru a oferi acces la un obiect ca o matrice obișnuită. Să ne uităm la un exemplu ca acesta:

set („nume”, „Dennis Pallett”); // Obține valoarea folosind get () echo $ registry-> get ("nume"); // Obține valoarea folosind array access echo $ registry ["nume"]?>

Trucul este că $ registry devine ca o matrice, când de fapt este un obiect. Desigur, ArrayAccess nu oferă avantaje speciale, dar vă permite să reduceți cantitatea de cod, deoarece nu trebuie să scrieți „-> get ()” de fiecare dată. Pentru a utiliza această interfață, trebuie să remediați prima linie a clasei ("Registrul de clasă") după cum urmează:

Registrul de clasă implementează ArrayAccess (

Cuvântul cheie Implements îi spune interpretului că aceasta este clasa în care implementăm interfața, ceea ce este ArrayAccess.

O clasă care implementează interfața ArrayAccess trebuie să aibă următoarele metode:

Funcția offsetExists ($ offset) (return isset ($ this-> vars [$ offset]);) function offsetGet ($ offset) (return $ this-> get ($ offset);) function offsetSet ($ offset, $ valoare) ($ this-> set ($ offset, $ value);) function offsetUnset ($ offset) (unset ($ this-> vars [$ offset]);)

Aceste metode ar trebui să se explice de la sine. Mai multe informații pot fi găsite în documentația SPL.

Acum că am implementat interfața ArrayAccess, putem accesa obiectul ca și cum ar fi o matrice obișnuită. Acest lucru este demonstrat clar, atât în ​​exemplul anterior, cât și în acesta:

get („nume”); // Obține valoarea folosind array access echo $ registry ["nume"]?>

Clasa Registry este acum completă și, dacă încercați să porniți sistemul, totul ar trebui să funcționeze (deși încă nu se va afișa nimic). Am terminat cu fișierul de inițializare și putem trece la pasul următor în scrierea sistemului nostru MVC: implementarea accesului la baza de date, care se numește „Model” în arhitectura MVC.

Model

„M” sau modelul este partea sistemului MVC care este responsabilă pentru interogarea bazei de date (sau altă sursă externă) și furnizarea de informații controlorului. Ar fi posibil să încărcați modelul necesar în funcție de solicitare, dar prefer să șterg ușor limitele dintre model și controler exact în acest punct, adică. controlerul lucrează cu baza de date direct prin biblioteca de interacțiune a bazei de date, mai degrabă decât printr-un model separat. Poate vrei să o faci altfel, e o chestiune de gust.

Trebuie să scriem codul necesar pentru a stabili o conexiune la baza de date și să-l punem în index.php. Există multe biblioteci grozave pentru a lucra cu baze de date (inclusiv a mea, AutoCRUD), dar PHP 5 are deja o astfel de bibliotecă - PDO. Prin urmare, nu este nevoie să utilizați altul.

Să introducem următorul cod în fișierul index.php (după conectarea fișierului de inițializare):

# Conectați-vă la baza de date $ db = PDO nou ("mysql: host = localhost; dbname = demo", "", ""); $ registry-> set ("db", $ db);

În acest exemplu, mai întâi creăm o nouă instanță a bibliotecii PDO și ne conectăm la baza noastră de date MySQL. Apoi facem variabila $ db disponibilă la nivel global folosind clasa noastră Registry.

Componenta model a sistemului nostru este gata, așa că să trecem la scrierea controlerului.

Scrierea unui controler înseamnă și scrierea unei clase Router care este responsabilă de încărcarea controlerului dorit în funcție de cerere (rețineți, în index.php, variabila $ route este trecută prin URL).

Clasa de router

Clasa Router va analiza cererea și apoi va încărca controlerul necesar. Să creăm un „schelet” al clasei:

registry = $ registry; ))?>

Apoi adăugați următoarele linii la index.php:

# Load router $ router = router nou (registru $); $ registry-> set ("router", $ router);

Primul lucru pe care îl vom scrie este metoda setPath () pentru a seta directorul în care vor fi localizate toate controlerele noastre. Metoda arată astfel și ar trebui adăugată la clasa Router:

Funcția setPath ($ cale) ($ cale = trim ($ cale, "/ \\"); $ cale. = DIRSEP; if (is_dir ($ cale) == false) (aruncă o nouă excepție ("Cale controler invalidă:` ". $ cale." `");) $ aceasta-> cale = $ cale;)

Apoi adăugați următoarele linii la index.php:

$ router-> setPath (cale_site. „controlere”);

Acum că am setat calea către controlerele noastre, vom scrie metoda însăși responsabilă pentru încărcarea controlerului. Această metodă va fi numită delegat () și va analiza cererea. Primul fragment al acestei metode este acesta:

Delegat funcție () (// Analizează calea $ this-> getController ($ fișier, $ controller, $ acțiune, $ args);

După cum puteți vedea, folosește o altă metodă, getController (), pentru a obține numele controlerului și alte câteva variabile. Această metodă arată astfel:

Funcția privată getController (& $ fișier, & $ controler, & $ acțiune, & $ args) ($ ruta = (gol ($ _ GET [„rută”)))? „”: $ _GET [„rută”]; dacă ( gol ($ traseu)) ($ ruta = "index";) // Obțineți părțile împărțite $ ruta = trim ($ ruta, "/ \\"); $ părți = exploda ("/", $ ruta); // Găsiți controlerul corect $ cmd_path = $ this-> cale; foreach ($ părți ca $ parte) ($ fullpath = $ cmd_path. $ Part; // Există un folder cu această cale? Dacă (is_dir ($ fullpath) ) ($ cmd_path . = $ part. DIRSEP; array_shift ($ parts); continua;) // Găsiți fișierul dacă (is_file ($ fullpath. ".php")) ($ controller = $ part; array_shift ($ părți) ; break;)) if (gol ($ controller)) ($ controller = "index";); // Obține acțiunea $ acțiune = array_shift ($ părți); if (gol ($ acțiune)) ($ acțiune = " index";) $ fișier = $ cmd_path. $ controler. ".php"; $ args = $ părți;)

Să trecem peste această metodă. În primul rând, ia valoarea variabilei de ruta $ din cerere, apoi o împarte în părți folosind funcția explode (). De exemplu, cererea „membri / vizualizare” ar fi convertită într-o matrice ca aceasta: matrice (‘membri’, ‘vizualizare’).

Apoi trece prin fiecare parte folosind o buclă foreach și verifică dacă acea parte este un director. Dacă este, atunci îl atașează la calea către fișier și verifică partea următoare. Acest lucru vă permite să puneți controlere în subdirectoare și, astfel, să obțineți o ierarhie de controlere. Dacă partea curentă a cererii nu este un director, ci un fișier, aceasta este salvată în variabila controller $ și ieșim din buclă, deoarece a fost găsit controlerul de care avem nevoie.

După buclă, verificăm variabila cu numele controlerului. Dacă este gol, atunci folosim controlerul „index”, care va fi controlerul nostru implicit. Metoda determină apoi acțiunea care trebuie întreprinsă. Un controler este o clasă care constă din mai multe metode. Acțiunea indică o metodă specifică. Dacă nu este specificată nicio acțiune, vom folosi „index” - acțiunea implicită.

În cele din urmă, obținem calea completă către fișierul controler prin concatenarea a trei variabile: calea, numele controlerului și extensia „php”.

Acum că am analizat cererea, este timpul să apelăm metoda delegate () pentru a încărca controlerul și a executa acțiunea. Metoda completă a delegatului () arată astfel:

Delegatul funcției () (// Analizați calea $ this-> getController ($ fișier, $ controller, $ acțiune, $ args); // Fișierul este disponibil? Dacă (is_redable ($ fișier) == false) (die ( "404 Not Found ");) // Includeți fișierul include (fișier $); // Creați o instanță a controlerului $ class =" Controller_ ". $ Controller; $ controller = noua clasă $ ($ this-> registry) ; // Este acțiunea disponibilă? If (is_callable (array ($ controller, $ action)) == false) (die ("404 Not Found");) // Execută acțiunea $ controller -> $ action (); )

După analizarea cererii folosind metoda getController (), verificăm dacă fișierul există într-adevăr, iar dacă nu, returnăm un simplu mesaj de eroare.

După aceea, conectăm fișierul cu controlerul și creăm o instanță a clasei sale, care ar trebui să se numească „Controller_ [nume]”. Despre controlere vom vorbi mai detaliat puțin mai târziu.

Apoi verificăm dacă acțiunea specificată (adică metoda) există și dacă este posibil să o apelăm (folosim funcția is_callable () pentru aceasta). În cele din urmă, efectuăm acțiunea în sine, care este rolul clasei Router și se termină.

Acum că am scris întreaga metodă delegate (), adăugați următoarea linie în fișierul nostru index.php:

$ router-> delegat ();

Dacă încercăm să pornim sistemul acum, vom vedea următoarea eroare (desigur, dacă directorul controlerelor nu există încă):

Eroare fatală: excepție neprinsă „Excepție” cu mesajul „Cale controler nevalidă:` g: \ Projects \ PHP \ content \ simple mvc php5 \ demo \ controllers \ `" în g: \ Projects \ PHPit \ conținut \ simplu mvc php5 \ demo \ classes \ router.php: 18 Stack trace: # 0 g: \ Projects \ PHP \ content \ simple mvc php5 \ demo \ index.php (13): Router-> setPath ("g: \ Projects \ PHP ... ") # 1 (principal) aruncat în g: \ Projects \ PHP \ content \ simple mvc php5 \ demo \ classes \ router.php pe linia 18

Sau vom vedea o eroare „404 Not Found”, deoarece încă nu există controlere. Dar asta este ceea ce vom face acum.

Controlor

Controlerele din sistemul nostru MVC vor fi destul de simple și vor dura foarte puțin. În primul rând, asigurați-vă că există directorul de controlere. Să creăm un fișier controller_base.php în directorul de clase și să lipim următorul cod în el:

registry = $ registry; ) index al funcției abstracte (); )?>

Această clasă abstractă va fi clasa părinte pentru toate controlerele noastre. Va face doar două lucruri: păstrează o copie locală a clasei Registry și folosește metoda index abstract () pentru a forța toți controlorii copii să implementeze această metodă.

Să scriem primul nostru controler. Să creăm un fișier index.php în directorul controlere și să lipim următorul cod în el:

Tocmai am creat primul nostru controler, iar dacă încercați să porniți sistemul, puteți vedea următoarele:

Aceasta înseamnă că clasa Router și-a făcut treaba și a declanșat acțiunea necesară de la controlerul necesar. Să scriem un alt controler care se potrivește cu cererea „membri/vizualizare”. Să creăm un fișier members.php în directorul controllers și să introducem următorul cod în el:

Acum să mergem la sistemul nostru MVC la cererea „membri / vizualizare” sau „index.php? Rută = membri / vizualizare”. Ar trebui să vedem un rezultat ca acesta:

Numai prin scrierea unui nou controler și adăugarea unei metode la acesta, am putut crea o pagină nouă și nu a trebuit să se schimbe nimic în sistemul în sine. De asemenea, controlerele noastre nu trebuie să includă un fișier global.php sau ceva de genul ăsta.

Acum că avem controlerele noastre, a mai rămas un singur lucru: „V” sau „View”.

Afişa

Ca și în cazul modelelor, există mai multe opțiuni diferite pentru a crea o componentă View într-un sistem MVC. Am putea învăța clasa Router să încarce automat un alt fișier numit ceva de genul „view_ (name) .php”. Dar pentru a face tutorialul mai clar, haideți să scriem o clasă Template care se va ocupa de redarea șabloanelor.

Mai întâi, creați un fișier template.php în directorul de clase și inserați următorul cod în el:

registry = $ registry; ))?>

Acum avem structura principală pentru clasa noastră Template. Următorul pas este să adăugați acest cod în fișierul nostru index.php, chiar înaintea liniilor asociate cu clasa Router:

# Creați un obiect șablon $ șablon = șablon nou (registru $); $ registry-> set ("șablon", $ șablon);

Deoarece trebuie să folosim valori de la modele și controlere, vom scrie o metodă set () pentru a seta variabilele disponibile în șabloane. Să ne uităm la un exemplu:

Set de funcții ($ varname, $ value, $ overwrite = false) (dacă (isset ($ this-> vars [$ varname]) == true AND $ overwrite == false) (trigger_error ("Nu se poate seta var` ". $ varname. "'. Deja setat și suprascrie nu este permisă.", E_USER_NOTICE); return false;) $ this-> vars [$ varname] = $ value; return true;) function remove ($ varname) (unset ($ this-> vars [$ varname]); returnează adevărat;)

Metodele set () și remove () sunt destul de simple și sunt folosite pentru a seta și, respectiv, a elimina variabile.

Să începem să scriem o metodă show () care va afișa șabloane. Cea mai simplă modalitate este de a crea un director separat de șabloane pentru a stoca toate fișierele șablon și de a folosi include () pentru a reda șablonul. Bineînțeles, propria metodă show () poate fi complet diferită și poate încărca șabloane din baza de date sau poate face altceva. Să ne uităm la kuso

Voturi: 745 | Vizualizari: 8080

În ciuda faptului că sensul expresiei „arhitectura site-ului” poate fi intuitiv pentru dvs., să încercăm să studiem o serie de definiţii deținute de surse reputate.

Arhitectură- aceasta este organizarea de bază a sistemului, întruchipată în componentele sale, relațiile acestora între ele și cu mediul, precum și principiile care determină proiectarea și dezvoltarea sistemului.

Arhitectură un program sau un sistem informatic este structura sau structurile unui sistem care includ elemente ale unui program, proprietățile acestor elemente vizibile din exterior și relația dintre ele [Bass].

Arhitectură este structura organizației și comportamentul asociat al sistemului. O arhitectură poate fi dezasamblată recursiv în părți care interacționează prin interfețe, relații care conectează părți și condiții de asamblare pentru piese. Părțile care interacționează prin interfețe includ clase, componente și subsisteme.

Arhitectură Un sistem software sau un set de sisteme constă din toate deciziile importante de proiectare privind structurile unui program și interacțiunile dintre acele structuri care alcătuiesc sistemul. Deciziile de proiectare oferă setul dorit de proprietăți pe care un sistem trebuie să le suporte pentru a avea succes. Soluțiile de proiectare oferă un cadru conceptual pentru proiectarea, asistența și întreținerea sistemului.

Deci, ce este arhitectura programului?

Definițiile date în secțiunea anterioară sunt prea uscate pentru a fi percepute de un cititor nepregătit. Vom încerca să explicăm esența cât mai simplu posibil.

Când programul devine suficient de mare, programatorul îl împarte în mai multe fișiere. Dacă nu vă gândiți să izolați grupuri de funcții similare și să le puneți în module separate, o astfel de împărțire va fi de puțin folos. Codul nu va fi reutilizabil și va fi dificil de navigat. Programul va fi dificil de extins și modificat.

Astfel, prima întrebare este în curs de elaborare: cum să împărțiți programul în fișiere. Arhitectura de fișiere a unui program este un aspect al structurii acestuia.

În timp ce evidențiază modulele sistemului, este necesar să se înțeleagă în ce relație vor fi acestea unul cu celălalt. De exemplu, modulele pentru accesarea bazei de date și procesarea imaginilor grafice cu greu au nevoie să știe ceva despre existența celuilalt. Dar modulul UI va ști despre ambele (și nu vor).

Relația dintre componentele unui sistem este determinată și de arhitectura acestuia.

În general, toate deciziile semnificative care vizează organizarea unui program, și nu problemele rezolvate cu ajutorul acestuia, pot fi atribuite arhitecturii.

Niveluri de abstractizare

La proiectarea modulelor (alegerea grupurilor de funcții și distribuirea lor între fișiere în cazul unei abordări procedurale), este important să selectați abstracțiile și să încercați să le descompuneți în mai multe niveluri.

Modulele de nivel scăzut sunt cât se poate de autonome, nu depind de alte părți ale programului. Modulele bine concepute izolează „lumea exterioară” de complexitatea sarcinii în cauză. Apelantul cunoaște doar interfața modulului (funcții externe), partea internă este închisă la acesta.

Să luăm ca exemplu o galerie foto. Informațiile despre imagini și utilizatori sunt stocate în baza de date, interfața cu utilizatorul este împărțită în partea client și panoul de administrare.

Structura programului ar putea fi cea prezentată în figura de mai jos:

Acest exemplu urmărește trei niveluri de abstractizare.

Orice program destinat uzului uman poate fi împărțit în cel puțin două niveluri: interfața cu utilizatorul și modelul. Modulul de interfață cu utilizatorul este conceput pentru a prezenta și vizualiza datele și pentru a procesa reacțiile utilizatorilor. Modelul conține logica problemei care se rezolvă și nu ar trebui să fie în niciun fel dependent de modul în care sunt afișate datele. Modelul ar trebui să fie ușor de portat între diferite tipuri de interfață cu utilizatorul.

Arhitectura MVC

Popular acum Model de design MVC... Acesta servește la separarea logicii aplicației de interfața cu utilizatorul. Dar mai întâi, să clarificăm ce este un model de design.

Acesta este un set de soluții tipice de design, un cadru al unei arhitecturi sau fragmentul acesteia. Dacă o bibliotecă este un pachet de cod reutilizabil, atunci un model de design este un pachet de soluții reutilizabile.

Deci, ce ne oferă MVC pentru a decupla logica aplicației de interfața cu utilizatorul?

Probă MVC vă permite să divizați datele, prezentarea și procesarea acțiunilor utilizatorului în trei componente separate:

1. Model... Modelul furnizează date (de obicei pentru Vizualizare) și, de asemenea, răspunde solicitărilor (de obicei de la Controlor) prin schimbarea stării acestuia;
2. Vedere... Responsabil cu afișarea informațiilor (interfață utilizator);
3. Controlor... Interpretează intrarea utilizatorului și informează modelul și vizualizarea cu privire la necesitatea unui răspuns adecvat.

Figura de mai jos arată relațiile dintre componentele unui cadru fir. Să ilustrăm imaginea cu un mic exemplu.

Imaginați-vă un formular în care puteți introduce text, faceți clic pe butonul Editați și obțineți transliterarea acestuia:

Să repetăm ​​pașii indicați în diagramă:

1. Utilizatorul face clic pe butonul Editare și Reprezentare(Vizualizare) trimite un mesaj Controlor(Controller): „Comandă: editați”
2. Controlorul acceptă mesaj și accesează Modelul apelând metoda Edit ().
3. Ca rezultat modificări de model starea acestuia (textul transliterat stocat în el) și notifică viziunea despre acesta: „Eveniment: schimbat”.
4. Depunerea durează semnal și se referă la model pentru o nouă valoare de rezultat apelând metoda Get ().

Implementarea MVC

Implementarea MVC presupune o abordare orientată pe obiecte (OOP). Cu toate acestea, un model de design este doar o colecție de soluții. Să le adaptăm pentru PHP fără a folosi OOP. Simplificarea se face pentru a se concentra asupra esenței separării logicii și, de asemenea, pentru ca materialul să poată fi aplicat de un cititor care nu este familiarizat cu OOP.

Luați în considerare din nou exemplu cu o galerie de fotografii.
Are două moduri de vizualizare:

1. Modul vizualizare miniaturi (toate odată);
2. Modul de vizualizare a fotografiilor la dimensiune completă (single).

Există și o posibilitate încarcă fotografii la server. În plus, vom implementa suport pentru tipurile de vizualizare pentru a aprecia flexibilitatea cadrului.

Site-ul va două puncte de intrare:

1. index.php (vezi galeria);
2. photo.php (vezi fotografia la dimensiune completă).

Aceste două fișiere vor fi luate în considerare Controlori.

La fel de Modele va exista un modul care oferă lucru cu stocarea imaginilor. Să-i spunem galerie.php si pune-l in folder model.

În rol Reprezentare Vor fi prezentate șabloane HTML, acestea vor fi localizate în folder șabloane... Ce sunt șabloanele și pentru ce sunt acestea - se va vedea în continuare.

Paginile de vizualizare a galeriei și de vizualizare a fotografiilor vor avea un antet și un subsol comune, doar partea centrală va diferi.

Vizualizarea galeriei va avea două tipuri de vizualizări:

1. Ca tabel (implicit);
2. Vizualizare listă.

Avem nevoie de patru șabloane:

1. main.php (scheletul paginii);
2. content_index_table.php (vizualizare tabelară a conținutului galeriei);
3. content_index_list.php (vizualizare listă a conținutului galeriei);
4. content_photo.php (conținutul paginii de vizualizare a fotografiilor).

Rezultă următoarea structură a site-ului:

Structura fișierului este împărțită de două linii orizontale care formează trei secțiuni. Fișierele din secțiunea superioară se referă la Model, fișierele din secțiunea din mijloc la Vedere, fișierele din secțiunea inferioară la Controler.

Model

Să începem cu implementarea Modelului. Codul de mai jos nu este complet furnizat pentru minimizarea și o mai bună claritate a exemplului.

Am definit doar interfața Model, lăsând implementarea sărită. Cu toate acestea, pentru implementarea de exemplu a cadrului MVC, nu este deloc necesar.

Reprezentare

Acum să ne uităm la șabloane. Să începem cu un schelet general de pagină:

Nu ar trebui să fii confuz de faptul că șablonul folosește o sursă necunoscută de variabile $ title și $ conținut. Aceștia vor fi înlocuiți de către Controlor. Dar mai multe despre asta mai târziu.

este o notație prescurtată .

Este convenabil să îl utilizați în șabloane. De asemenea, este mai convenabil să folosiți variante alternative de scriere a construcțiilor if-else, foreach, for, while în șabloane. Arata asa:

Dacă (<условие>): <тело>endif; pentru fiecare (<инициализация цикла>): <тело>endforeach;

Restul șabloanelor vor fi inserate în main.php în acest fel:

În exemplele de mai jos, codul lor este afișat:

Șabloane / cod content_index_table.php

masa| Listă

"> " />

Șabloane / content_index_list.php

Tabel | Listă

"> " />

templates / content_photo.php: Înapoi

" />

Controlor

În cele din urmă, să punem totul împreună, descriind cele două controlere ale noastre. Sarcina lor este să proceseze cererea, să selecteze un șablon și să înlocuiască datele cerute de șablon. Datele sunt preluate, de regulă, din model.

Controlerul galeriei încarcă o fotografie dacă utilizatorul a încărcat un fișier. În caz contrar, extrage o listă de fotografii din model, selectează șablonul dorit (în funcție de dorința utilizatorului) și afișează acest șablon, trecându-i o listă de fotografii:

Codul index.php

Controlerul de vizualizare a fotografiilor este și mai simplu:

Cod foto.php

In cele din urma

Încercați să acordați suficientă atenție arhitecturii aplicației dvs. Dacă inițial creați un cadru puternic și extensibil, efortul va da roade o sută de ori.

Pentru a implementa modelul MVC, este mai bine să alegeți abordare orientată pe obiect .

Există multe soluții de cadru ieșite din cutie, de exemplu în Zend Framework. Cu toate acestea, informațiile din lecția curentă sunt suficiente pentru a înțelege soluțiile arhitecturale MVC și pentru a începe să le utilizați acum.

Ce este MVC?

Deci, MVC se referă la interfața cu utilizatorul (UI). Nu neapărat grafic, și controlul vocal este bine. Să nu uităm că un program poate să nu aibă o interfață cu utilizatorul, poate să aibă o interfață de programare (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 adiacentă dintre cele 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. Ea știe să facă ceva util, iar utilizatorul are nevoi care pot fi satisfăcute cu acest program. Apoi apar bucăți de logică care „știu” cum, folosind acest program, să facă direct ceea ce dorește utilizatorul. Piesele nu sunt subiecte, logica subiectului în program. Acestea sunt mai mult legate de 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 plasează o aplicație în care indică că dorește să cumpere 20 de acțiuni ale companiei Svetlyi Put la un preț de 1.500 RUB per acțiune. De asemenea, indică faptul că cererea este valabilă patru ore, și din care dintre conturile sale ar trebui să fie debitați banii, în cazul unei tranzacții reușite.

Un număr tangibil de atribute. Trece ceva timp și își dă seama că nu va fi posibil să cumpere la un astfel de 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ă un preț nou, da. Este confortabil.

Dar ordinea nu poate fi schimbată la schimb, nu există un astfel de concept în domeniul subiectului. Aplicația poate fi doar plasată și anulată. Pentru a oferi utilizatorului posibilitatea de a schimba o aplicație cu un singur clic, este necesar să rețină valorile vechi, să anuleze aplicația, să dea să editeze ceea ce a memorat și să trimită o nouă cerere. O astfel de combinație. Dar utilizatorului i se pare o acțiune simplă: schimbarea biletului. Acesta se numește caz de utilizare.

Să completăm diagrama noastră cu un loc pentru cazuri de utilizare.

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

Utilizatorul folosește unele dintre cazurile de utilizare, care, la rândul lor, manipulează programul. Programul publică rezultatul sau modifică starea acestuia.

Deci unde este MVC la fel?

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

Când modelul publică modificările, 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 variantă clasică MVC - Active Model. De asemenea, se întâmplă ca modelul să nu anunțe despre modificări. Atunci controlorul preia această responsabilitate. Știe ce fel de 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 condiționată și depinde de cât de pedant vrem să modelăm domeniul de subiect. Uneori este o decizie rațională să includeți un caz de utilizare în model. Poate că acest lucru va reduce cantitatea de cod în general și o va simplifica.

Pentru material îi mulțumim abonatului nostru Stanislav Ilyichev