Commentariile voastre

MVC 1: Concept si implementare

Autor Vlad Fratila
Adauga
Toate
come sociale vorbeam de o aplicatie complexa si
Intr-un articol precedent din seria comunitatilor
usurinta cu care ea poate fi executata folosind un framework de tip MVC. Practic, aceasta
arhitectura/modalitate de lucru se potriveste perfect pentru orice tip de proiect, fiind foarte
recomandat pentru cele de anvergura.

Cum construim cel mai usor o aplicatie mare? O impartim pe sectiuni, desigur. Avem astfel
avantaje multiple: se poate lucra in echipa mult mai usor, putem gasi repede partea de
aplicatie de care avem nevoie si ii putem oferi o anume individualitate. As vrea sa explic acest
ultim punct: sa spunem ca avem o aplicatie ale carei templateuri sunt parsate cu Smarty.
Vrem totusi ca o parte a aplicatiei (sa spunem back-endul sau un modul care face pdfuri) sa
nu foloseasca Smarty. Prin MVC acest lucru este foarte simplu: va fi redus la setarea unei
variabile.

MVC este o arhitectura care se invarte exact in jurul acestei idei. Aplicatia noastra va fi
impartita in mai multe sectiuni, carora le vor corespunde cate doua clase. MVC vine de la
Model View Controller, reprezentand cele trei componente principale ale unei aplicatii.

Modelul reprezinta partea de hard-programming, logica aplicatiei. El este responsabil de

actiuni precum operatiile asupra datelor, integrarea cu baza de date, autentificarea userilor
etc. Modelul reprezinta astfel o colectie de clase ce vor indeplini anumite functii, fara legatura
cu actiunile userului. Ele vor fi baza pentru orice functie pe care va trebui sa o indeplineasca
siteul.

View-ul se ocupa de afisarea datelor. O data ce functiile sunt executate de model, viewului ii
sunt oferite rezultatele, iar acesta le va trimite catre browser. Viewul va folosi deci anumite
templateuri, in functie de setarile oferite de model.

Controller-ul este legatura intre model si view, intre logica aplicatiei si actiunile userului. In
functie de cerintele userului, controllerul va executa o anumita functie definita special pentru
sectiunea de site in care se afla userul. Functia va folosi modelul pentru a prelucra datele si
va trimite rezultatele catre view, care isi va afisa apoi templateurile.

Mai tarziu voi da un exemplu, pentru a intelege bine cum poate fi implementat acest lucru.

De ce ai nevoie pentru a face un webapp?

Intrebarea este foarte fireasca. Ce iti trebuie pentru a crea un site in PHP? Presupunand ca
vrem sa lucram cu obiecte, intrebarea poate suna si altfel: de ce clase avem nevoie pentru a
incepe lucrul la un site? Sa incercam sa raspundem. In primul rand, vom avea nevoie de o
clasa care sa lucreze cu baza de date. Urmatorul lucru la care ma gandesc este o clasa de
autentificare. Apoi una care sa ne rezolve templatingul(V-ul din MVC). Dar sa le asezam intr-o
ordine. Am spus ca toate vor fi subordonate modelului. Deci:
MODEL
- db – vom vrea desigur sa facem clase diferite pentru fiecare tip de baza de date: mysql,
msssql, sqlite, oracle, adodb etc.
- authentication – poate vom dori mai multe tipuri de autentificare:
- HTTPAuth prin .htaccess
- autentificare obisnuita cu baza de date
- LDAP
- file handling
- debugging
- caching

Toate acestea vor fi clase care ne vor ajuta sa ne prelucram datele. Cum vom afisa toate
acestea? Exista desigur mai multe modalitati, dintre care as aminti cateva:

VIEW
 html simplu
 smarty
 rest/xml
 pdf
 poate am dori si o clasa speciala pentru rss, separata de cea generala xml

Acesta este modelul, acesta este viewul. Daca aveti nevoie de alte clase, le puteti
adauga la lista. Ne vom ocupa imediat si de implementarea lor. Dar mai intai...

Cate ceva despre controller

Ideea controllerului se impleteste cu insasi structura siteului si cu modul in care userii il

vor accesa. Adica, cu forma URLurilor. Pare simplu? Nu va asteptati la asa ceva? Am
spus ca un controller va trebui sa preia inputul userilor si sa ruleze actiuni
corespunzatoare lui, pentru a-i oferi view-ului valorile de care are nevoie. Aceste
actiuni vor fi numite in URL. Nu va ganditi la datele din POST. Pe acelea le veti avea
oricum. Ceea ce este important este in ce sectiune – model – este userul si care este
actiunea pe care o executa. Ca sa intelegem mai bine, actiunea este un fel de
subsectiune. De exemplu, un forum simplu are ca actiuni: viewtopic, viewthread,
newthread si newreply.

URLurile noastre vor fi de forma: ?model=posts&action=viewthread&param1=15. De

ce param1? Este un standard pe care vi-l impuneti si este mai simplu pentru rescriere.
Cei care nu stiu, exista un tutorial aici despre mod_rewrite si URLuri frumoase. Eu mi-
am facut URLuri de tipul posts/viewthread/15/. Easy.

Ce face controllerul? In general bine. Vede care este modelul. Apoi vede care este
actiunea care trebuie executata. Actiunea va fi o functie intr-o clasa, veti vedea
imediat. Acolo, in acea functie, veti scrie tot codul PHP de care aveti nevoie. Apoi
controllerul va chema automat viewul, care va randa pagina conform htmlului
corespunzator modelului. MVC 2 - Si cum fac toate astea?
 Daca cineva a zis acum „exact!!”, inseamna ca primul articol a fost interesant si
provocator. Hai sa vedem.

In primul rand, fiecare obiect va porni de la o clasa de baza. Aceasta ne va ajuta sa

oferim fiecarei clase anumite functii comune si va permite claselor sa interactioneze
intre ele. Iata, din nou, lista cu toate clasele pe care le vom implementa:
 BaseObject
 - iModel
 idb
 - dbmysql
 - dbmssql
 - dbpostgresql
 - dbsqlite
 auth
 files
 cache
 debugger
 - iController
 - iView
 - VSimpleHTML
 - VSmarty
 - VPdf
 - VXML
 - VRSS

Clasele care incep cu i sunt interfete, ceea ce inseamna ca nu pot face nimic singure. Ele
reprezinta puncte de plecare pentru alte clase. Acestea sunt iModel, iView si iController, dupa
cum era de asteptat. Sa vedem cum le vom initializa.

Fiecare sectiune a siteului va reprezenta un Model, caruia ii va corespunde un Controller.

Modelul va extinde clasa iModel, continand astfel tot ce contine aceasta clasa: conexiunea la
baza de date, instanta catre clasa de autentificare etc. De obicei, in clasa Model vom defini
decat anumite setari, cum ar fi motorul bazei de date folosita de model, tabelul din baza de
date, daca are nevoie sau nu de autentificare etc. Daca modelul are nevoie de functii speciale
de prelucrare a datelor, aceasta clasa va fi locul in care acestea vor fi declarate.

Toate aceste functii vor putea fi folosite in clasa de controller. Fiecare model va avea o astfel
de clasa. Ea va fi compusa din functii care vor corespunde actiunilor modelului, astfel incat un
url de tipul ?model=posts&action=viewthread sa rezulte in executarea de catre controller a
functiei viewthread() din clasa controller_posts, care este cuplata la randul ei de clasa
model_posts.

Va puteti pune intrebarea: de ce avem nevoie de doua obiecte, unul pentru model si altul
pentru controller? Am putea face acele configurari de care vorbeam direct in clasa de
controller, ba chiar am putea defini functii de prelucrare a datelor direct aici. Va voi raspunde
ca se poate, da, puteti face asta. Insa ideea MVC-ului este sa separe logica aplicatiei de
prezentare. Controllerul nu se va ocupa decat de obtinerea datelor de care viewul are nevoie,
apeland functii definite in model. Totul este mult mai separat si mult mai clar in acest fel.
Desigur, voi puteti face precum doriti. Nu este neaparata nevoie de doua clase, insa este
recomandat. Ganditi-va la un site mare... si ganditi-va ca e bine sa va invatati de mici ordonati
:P

Vreau sa prezint structura de directoare a unui astfel de framework, preluata din cel pe care Il
dezvolt, Qualia. Sper ca asta sa faca putin mai clar lucrurile:

App
 controllers – toate clasele de controller
 models – toate clasele de model
 views – va contine un subdirector pentru fiecare model, in care vor fi stocate
templateurile
 public - vor fi cssurile, imaginile, jsurile, headerele comune tuturor paginilor etc –
practic skinul/skinurile
Framework
 abstraction – aici tin interfetele: baseobject, iModel, iController, iDB, iView
 models – modelele care vin cu frameworkul – deocamdata am clasele specifice
diferitelor baze de date
 controllers – controllere standard
 views – clasele de views: VSimpleHTML, Vsmarty etc si alte clase de ajutor in view
 si inca clase secundare, de ajutor general – de ex aSanitize pentru securitate,
aFileHandler etc
Conf
 fisierele de configurare

3rdparty
 aplicatii ca smarty, script.aculo.us etc.

Va sfatuiesc sa aruncati un ochi peste CakePHP si peste Symfony. Primul se apropie

mult de ce descriu aici, iar al doilea este mai complicat, insa foarte puternic. Si va
astept data viitoare sa vedem cum implementam masinaria aceasta.