MVC 1: Concept si implementare

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¶m1=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

o idb
o - dbmysql
o - dbmssql
o - dbpostgresql
o - dbsqlite
o auth
o files
o cache
o debugger


* - iController
* - iView

o - VSimpleHTML
o - VSmarty
o - VPdf
o - VXML
o - 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 Razz


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