Conectare

Mi-am uitat parola

Panou De Control
Profilul tau
Informatii
Preferinte
Semnatura
Avatar
Social
Lista de prieteni si lista userilor ignorati
Membrii forumului
Grupuri de utilizatori
Mesaje private
Mesaje primite
Mesaje trimise
Subiecte monitorizate
Subiecte monitorizate
Parteneri
Steel Arena
Sondaj

Cum vi se pare siteul nostru?

81% 81% [ 13 ]
13% 13% [ 2 ]
0% 0% [ 0 ]
0% 0% [ 0 ]
6% 6% [ 1 ]

Total voturi : 16

Cuvinte-cheie


MVC 1: Concept si implementare

In jos

MVC 1: Concept si implementare

Mesaj Scris de +gZ.Flyking la data de Mier Iun 10, 2009 11:55 am

Intr-un articol precedent din seria comunitatilor sociale vorbeam de o aplicatie complexa si 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¶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
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. 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.

_________________
One shot, one opportunity, one kill.
Let there be banned users!
avatar
+gZ.Flyking
Administrator
Administrator

Numarul mesajelor : 237
Data de inscriere : 05/06/2009
Varsta : 23
Localizare : Galati

Vezi profilul utilizatorului

Sus In jos

Sus


 
Permisiunile acestui forum:
Nu puteti raspunde la subiectele acestui forum