ModelViewController

Cuprins Busuioc Andrei - prezentare generala, editare Context Problema Solutia Istoric Implementare unctionare Variatii Bibliogra!ie Constanzo "iccardo - model Model "oluri Comunicare model-#iew Bibliogra!ie Codita Bogdan Alexandru - #iew View Ierar$ia #iew%sub#iew A!isarea View "esponsabilitati in MVC "elatia #iew-controller "elatia #iew-model Bibliogra!ie Ciuca Alexandru - controller Controller Implementare Bibliogra!ie

Context In general, scopul multor computere este acela de a prelua in!ormatii dintro anumita locatie, de a o prelucra dupa pre!erintele utilizatorului si, in cele din urma, de a o a!isa utilizatorului& 'upa ce utilizatorul modi!ica continutul in!ormatiei si dupa aplicarea unor e#entuale procesari aditionale, sistemul reinoieste in!ormatia in locul de unde a preluat-o initial& Cea mai usoara metoda de a realiza o aplicatie care realizeaza aceste operatii este de a pune laolalta operatiile si de a le trata ca pe un tot& Aceasta metoda este buna in sensul ca este usor de implementat& (lterior apar insa probleme cand se doreste sc$imbarea uneia din componentele !luxului de date, spre exemplu atunci cand se doreste sc$imbarea inter!etei& ) alta problema tine de logica de business ce trebuie incorporata, logica care si ea este supusa sc$imbarilor si care merge dincolo de simpla intersc$imbare de in!ormatie& Problema Apare asadar ne#oia de a modulariza aplicatia, de a delimita in mod clar partile componente spre a putea !i usor modi!icate si ca dupa modi!icare sa !ie inca compatibile cu celelalte module ce !ormeaza aplicatia& Solutia ) solutie la aceasta problema este ar$itectura Model-View-Controller (MVC) care separa partea de stocare a datelor de cea de prezentare si de prelucrare& A#em asadar trei clase distincte* Model-ul se ocupa de comportarea si datele aplicatiei; raspunde la cereri despre starea sistemului, la cereri de schimbare de stare si notifica utilizatorul atunci cand aceste schimbari au avut loc pentru ca acesta sa poata reactiona. View-ul transpune model-ul intr-o forma care permite o interactionare usoara, in mod tipic o interfata vizuala. Pot e ista multiple view-uri pentru un sin!ur model pentru scopuri diferite. Controller-ul primeste input de la utilizator si initiaza un raspuns in urma cererilor catre obiectele model. Controller-ul este cel care controleaza celelalte doua clase de obiecte, view si model, instructandu-le sa e ecute operatii pe baza input-ului primit de la utilizator.

"ia!rama arhitecturii MVC prezinta liniile solide ca asocieri directe iar liniile punctate ca asocieri indirecte. Istoric MVC a !ost descris pentru prima oara in +,-, de catre .r/g#e "eens0aug care pe #remea aceea lucra la Smalltal0 din cadrul 1erox PA"C& Implementarea originala este descrisa in detaliu in lucrarea #pplications Pro!rammin! in $malltal%-&'( )ow to use Model*View*Controller & Implementare ) aplicatie orientata pe principiile MVC poate !i o colectie de triade model%#iew%controller, !iecare responsabila de un element di!erit al inter!etei cu utilizatorul& MVC este des intalnit in in aplicatii web unde #iew-ul este codul 2.M3 generat de aplicatie& Controller-ul primeste #ariabile 45. si P)S. ca si input si decide ce sa !aca cu acestea, trimitandu-le mai departe model-ului& Model-ul, care contine logica de business si regulile a!erente, poate e!ectua operatiile necesare asupra datelor pentru a putea permite aplicatiei generarea codului 2.Ml mai sus mentionat #ia engine-urile de template, pipeline-uri 1M3, cereri de tip A6ax, etc& Model-ul nu este neaparat doar o baza de date, !iind adesea atat baza de date cat si logica de business necesara pentru a manipula datele in interiorul aplicatiei& Multe aplicatii !olosesc un mecanism persistent de stocare a datelor& MVC nu speci!ica in mod explicit ni#el de acces la date tocmai pentru ca este de la sine inteles ca acesta se a!la incapsulat in model& In unele aplicatii simple care au putine reguli de business logic impuse, model-ul se poate limita doar la o baza de date si la !unctionalitatile o!erite de aceasta&
3

View-ul, de asemenea nu este limitat doar la a!isarea in!ormatiei, el a#and un rol important si in interactiunea cu utilizatorul& In cazul exemplului de mai sus al aplicatiilor web inter!ata generata #ia cod $tml este cea care se ocupa si de preluarea input-ului si de masurile luate pentru ca acesta sa !ie corect& Controller-ul este adesea con!undat cu aplicatia insasi, pe cand rolul sau este de a diri6a datele intre celelalte doua clase de obiecte& Intr-ade#ar, se pot executa multe operatii asupra datelor de catre model, insa aceste operatii tin de !ormatul in care se prezinta datele la un moment dat& Adesea se intalneste cazul in care datele a!isate%culese de la utilizator di!era semni!icati# de cele stocate in baza de date& Aceste di!erente se datoreaza con#ersiilor ce pot !i aplicate asupra datelor de catre controller pentru a !acilita tra!icul de in!ormatie intre componente& iecare clasa de obiect are anumite expectati#e de!inite in ceea ce pri#este !ormatul datelor, ori aceste trans!ormari de !ormat trebuie realizate automat pentru a mentine un !lux constant de date, degre#and celelalte clase de gri6a con#ersiilor si asigurand aplicatia ca !iecare modul primeste ceea ce asteapta& Asta pe langa !unctia de baza de controla tra!icul de cereri intre module& Functionare Sc$ema de !unctionare a unei aplicatii modelate dupa ar$itectura MVC decurge, in linii mari, in !elul urmator* +& (serul interactioneaza cu inter!ata& 7exemplu* apasa un buton la tastatura8 9& Controller-ul primeste actiunea apasarii butonului si o con#erteste intr-o actiune pe intelesul model-ului& :& Controller-ul noti!ica model-ul de actiunea utilizatorului, urmand de obicei o sc$imbare a starii model-ului& 7exemplu* model-ul reimprospateaza starea campului de adresa8 ;& (n #iew interog$eaza model-ul pentru a genera o inter!ata corespunzatoare& 7exemplu* #iew-ul a!iseaza noua adresa alaturi de cea #ec$e alaturi de un buton de con!irmare8 <& Inter!ata asteapta actiuni suplimentare din partea utilizatorului, ciclul reluandu-se&

Variatii In #pplication Pro!rammin! in $malltal%-&'( )ow to use Model-ViewController (MVC), Ste#e Burbec0 descrie doua #ariante de MVC* un model pasi# si un model acti#& Modelul pasi# este !olosit cand un controller manipuleaza model-ul exclusi#& Controller-ul modi!ica model-ul si apoi in!ormeaza #iew-ul ca model-ul a !ost sc$imbat si ca trebuie reimprospatat& In acest scenariu model-ul este complet independent de #iew si controller, ceea ce inseamna ca model-ul nu are cum sa raporteze sc$imbarile sale de stare& Protocolul 2..P este un exemplu eleoc#ent al acestui model pasi#& Browserul nu are cum sa primeasca update-uri asincrone de la ser#er& Browserul a!iseaza #iew-ul si raspunde la input utilizator dar nu detecteaza sc$imbari in datele de pe ser#er& 'oar atunci cand utilizatorul cere in mod explicit o reimprospatare ser#erul este interogat pentru e#entualele sc$imbari& Modelul acti# este !olosit cand model-ul isi sc$imba starea !ara implicarea controller-ului& Acest lucru se poate intampla cand alte surse sc$imba datele iar sc$imbarile trebuie re!lectate in #iew-uri& (n exemplu de ast!el de model implementat este banda de stiri in timp real a canalelor de stiri& Aceasta a!iseaza in timp real datele din baza de date pe masura ce acestea sunt modi!icate& 7pe masura ce noi stiri sunt adaugate8 .otusi, pentru a a#ea acest model ar insemna ca #iew-ul sa !ie dependent de model, ori noi dorim ca ambele sa !ie independente unul de celalalt& Introducem notiunea de observator care este un obiect ce noti!ica celelalte obiecte de sc$imbari de stare !ara a introduce dependente intre acestea& Viewurile se subscriu la obser#ator pentru a primi noti!icari& Cand un model se sc$imba el noti!ica toate obser#atoarele atasate lui de sc$imbarea produsa& 3a randul lor, obser#atoarele noti!ica #iew-urile de sc$imbarile raportate lor& Aceasta metoda este cu atat mai e!icienta cu cat exista un numar mai mare de
5

modele si view-uri care opereaza dupa modelul dinamic. Cum model-ul este decuplat de #iew #ia obser#ator&

unctionarea modelului acti# pe baza de noti!icari trimise prin intermediul unui obser#ator&

Bibliografie +& MS'= 3ibrar/ - $ttp*%%msdn&microso!t&com%en-us%librar/%!!>;,>;:&aspx 9& ?i0ipedia&org - $ttp*%%en&wi0ipedia&org%wi0i%Model@59@AB@,:View @59@AB@,:Controller

Model Modelul este inima aplicatiei, partea care nu se sc$imba& Modelul este partea ce contine datele, in!ormatiile despre utilizatori& 5ste, in general, principalul obiecti# al programatorilor, el constituind marea parte a e!ortului de programare& Modelul este cel ce raspunde anumitor comenzi si cel ce comunica cu baze de date externe& Model-ul are ne#oie de o baza de data unde sa stoc$eze permanent datele, care baza de date poate !i incapsulata in model sau poate !i la o anumita locatie cunoscuta de model& .otusi, in aplicatii mai usoare, model-ul poate !i con!undat cu baza de date insasi, daca operatile pe care le !ace model-ul sunt operatii !oarte simple& Intr-o aplicatie creata ast!el incat sa respecte acest concept, partea de model #a lucra doar cu starea aplicatiei si cu logica ei, nu #a conta cum este sau #a !i reprezentata aceasta stare catre utilizator sau cum interactioneaza acesta cu aplicatia& (n alt aspect important este ca atat #iew-ul, cat si controller-ul depind de model-ul, in timp ce model-ul nu depinde de ele& Ast!el modelul poate !i implementat si testat !ara sa !ie ne#oie de inter!ata gra!ica, dez#oltarea acesteia !acandu-se in paralel& Model-ul este utilizat la organizarea in!ormatiei si anuntarea cCnd aceasta se modi!ica& 5l contine doar date si !unctionalitati care sunt legate printr-un scop comun& 'aca ar !i !ost cazul de a modela date din doua grupuri care nu sunt legate intre ele, s-ar !i creat doua modele separate& (n model #a contine mai mult decat date si !unctii care opereaza pe aceste date& Scopul unui model este de a realiza o aproximare, sau abstractizare, in mediul in!ormational al unor procese sau sisteme din lumea reala& 5l nu trebuie sa se limiteze la a captura starea unui preces sau sistem, ci c$iar la cum acel sistem !unctioneaza, ceea ce !ace !oarte usoara !olosirea modelarii din lumea reala la de!inirea propriilor sisteme&

Rolurile partii de model Partea de model inmagazineaza datele sub !orma de proprietati si pune la dispozitie metode speci!ice aplicatiei care permit extragerea si !ixarea datelor& Metodele care gestioneaza datele nu sunt ce#a generic, ele sunt adaptate cerintelor aplicatiei si trebuie sa !ie cunoscute partilor de control si de #edere& 'atele din cadrul partii de model pot !i modi!icate extern de catre o clasa externa sau intern ca urmare a logicii proprii& Partea de model trebuie sa puna la dispozitie o modalitate prin care #ederile sa !ie inregistrate sau sa iasa din e#identa singure, si modelul sa organizeze o lista a #ederilor inregistrate& 'e !iecare data cCnd modelul obser#a o sc$imbare importanta a propriei starii, trebuie sa anunte toate #ederile inregistrate& In !inal, modelul este acela care implementeaza partea logica a DtriadeiE MVC& 'e asemenea el !urnizeaza si ser#icii de #alidare a datelor si alte utilitatii speci!ice aplicatiei& Comunicare model - view In mod normal, modelul nu are nici o in!ormatie in legatura cu #iew& .otusi exista o comunicare intre aceste 9 parti si ea are loc daca* A !ost apasat un buton si a !ost trimisa o comanda model-ului& ) #aloare noua a !ost scrisa intr-un Dtext !ieldE si un mesa6 de actualizare a !ost trimis model-ului& 'aca o #aloare este necesara #iew-ului, o cerere ii este trimisa model-ului pentru acea #aloare& Ast!el, comunicarea are loc daca se intampla un e#eniment& View-ul trimite o cerere catre model care trebuie sa !ie capabil sa o desci!reze si sa ii trimita un raspuns, indi!erent daca acest raspuns este o #aloare sau o serie de operatii mai complicate& Bineinteles ca este ne#oie de o programare buna a modelului care trebuie sa !ie capabil sa desci!reze un numar mare de ast!el de operatii& Bibliografie $ttp*%%en&wi0ipedia&org%wi0i%Model@59@AB@,:View@59@AB@,:Controller $ttp*%%www&worldit&in!o%articole%introducere-in-design-patterns-m#c-partea-i% $ttp*%%www&securenet&ro%ro%publications%doc%'ez#oltareaFaplicatiilorFweb&pd! $ttp*%%www&enode&com%x%mar0up%tutorial%m#c&$tml $ttp*%%msdn&microso!t&com%en-us%librar/%!!>;,>;:&aspx $ttp*%%msdn&microso!t&com%en-us%librar/%!!>;,>;:&aspx

VI ! View este una dintre cele trei componente ale ar$itecturii Model-ViewController si are rolul de a atribui Model-ului o !orma adec#ata pentru interactiune, de obicei un element de inter!ata cu utilizatorul& Pot exista mai multe #iew-uri pentru acelasi model& 'e !iecare data cand este sc$imbat modelul, !iecare #iew al modelului este anuntat ca trebuie sa sc$imbe reprezentarea #izuala pe ecran& ) regiune a a!isa6ului care nu este in concordanta cu in!ormatia primita de la model se numeste DdaunatoareE sau Din#alidaE& Cand se !ace o sc$imbare, #iew identi!ica partea de ecran modi!icata si o raporteaza la Dsistemul de !erestreE ca !iind in#alida& Acesta con!irma zona DstricataE, urmand sa !ie redesenata de catre #iew&

In Ga#a putem !olosi inter!ata D6a#a&util&)bser#erE ca baza a componentei #iew, inter!ata ce cuprinde subclasa D6a#ax&swing&GpanelE& In urmatorul exemplu, #iew este implementat in clasa 'iagramView& Implementarea a !ost simpli!icata ast!el incat o mica sc$imbare a modelului pro#oaca redesenarea& Acest lucru este realizat in !unctie de update-ul din inter!ata )bser#er*

public class 'iagramView extends Gpanel implements )bser#er H public #oid update 7)bser#able o, )b6ect arg8 H i! 7arg instanceo! 'iagram&=ode8 H rc$ace&remo#e7arg8I J repaint78I J J View decide asupra reprezentarii actuale a diagramei& Singurele lucruri adaugate conexiunii sunt titlurile si punctul central al nodurilor& View trebuie sa retina in!ormatiile despre dreptung$iurile de selectie ale nodurilor 7$arta structurii de date rcac$e8& I R"R#I" VI !$S%BVI ! View-urile sunt construite pentru a !i imbricate& Cele mai multe !erestre contin doua #iew-uri, unul imbricat in celalalt& View-ul extern, cunoscut ca topView, este o instanta a StandardS/stemView sau o subclasa a lui& StandardS/stemView gestioneaza !iecare atribut din tabelele !erestrei& In interiorul topView sunt unul sau mai multe subView-uri care au controlere asociate ce gestioneaza optiunile de control disponibile pentru !iecare View& 'e exemplu, un Dwor0spaceE !amiliar are StandardS/stemView ca topView si String2olderView ca subView& (n subView poate a#ea, optional, alt subView, dar asta se intampla !oarte rar in aplicatii& "elatiile subView%superView sunt inregistrate in #ariabile mostenite de la View& iecare View are o #ariabila superView in care se contine pe sine si contine si alte subView-uri care reprezinta )rderedCollection pentru subView-uri& Ast!el, topView-ul din !ereastra reprezinta #ar!ul ierar$iei, urmand apoi #ariabilele superView si subView& In continuare #oi prezenta un exemplu care contruieste si lanseaza o DtriadaE MVC& Acest exemplu este o #ersiune simpli!icata a codului care desc$ide Dmet$od3istBrowserE-browser-ul pe care il #edem cand alegem implementatorii si expeditorii din lista de metode a subView-urilor& SubView-ul superior a!iseaza o lista de metodeI cand selectam o metoda, codul sau apare in subView-ul in!erior& In exemplu #oi numerota liniile de cod pentru a !ace re!erire mai usor la ele cand le #oi explica*

10

+& 9& :& ;& <& >& -& A& ,& +B& ++& +9& +:& +;& +& 9& :& ;& <-,& +B-+:& +;&

open3istBrowser)n* aCollection 3abel* labelString initialSelection* sel KCreate and sc$edule a Met$od 3ist browser !or t$e met$ods in aCollection&K LtopView aBrowserL aBrowser*MMet$od3istBrowser new on* aCollection topView*MBrowserView new& topView model* aBrowserI controller* StandardS/stemController newI label* labelString asStringI minimumSize* :BBN+BB& topView addSubView* 7SelectionIn3istView on* aBrowser printItems* !alse oneItem* !alse aspect* Omet$od=ame c$ange* Omet$od=ame* list* Omet$od3ist menu* Omet$odMenu initialSelection* Omet$od=ame8 in* 7BNB extent* 1.0@0.258 border?idt$* +& topView addSubView* 7CodeView on* aBrowser aspect* Otext c$ange* Oaccept.ext*!rom* menu* OtextMenu initialSelection* sel8 in* 70@0.25 extend* 1@0.758 border?idt$* +& topView controller open Creare model Creare topView 7in general acesta este StandardS/stemView, dar in acest exemplu am !olosit BrowserView care este o subclasa a StandardS/stemView8 Speci!icare model si controler 7daca nu speci!icam controler-ul, el este !urnizat de metoda de!aultController cand este prima data apelat8 Speci!icare dimensiunea minima pentru topView Instalare subView superior care este SelectionIn3istView Instalare subView in!erior 'esc$idere controler&

"FIS"R " VI ! View poate a#ea ne#oie de propriul protocol de a!isa6 care #a !i utilizat atat pentru a!isarea imaginii initiale, cat si pentru rea!isarea imaginii in cazul unei sc$imbari a modelului& 'upa o actualizare a modelului, View trimite Dpropriul a!isa6E 7sel! displa/8& DView displa/E trimite pe rand Dsel! displa/BorderE, Dsel! displa/ViewE, Dsel! displa/Sub#iewsE& 'aca View cere o a!isare speciala di!erita de cea mostenita, el considera a!isarea ca !iind una dintre cele trei enumerate mai sus& Pentru di#erse te$nici de a!isare putem cauta implementari in
11

displa/View& )bser#am modi!icari ale a!isa6ului in !unctie de !iecare metoda !olosita& Sc$imbarile a!isa6ului sunt instante ale ?indowing.rans!ormation& 5le diri6eaza scalarea si translatarea in !unctie de conexiunea la !ereastra si la porturile View-ului& ) !ereastra este o intrare a trans!ormarii& 5ste un dreptung$i intr-un a!isa6 abstract a#and coordonate arbitrare in sistem, dar apropiate de ne#oile aplicatiei noastre& (n port este reprezentat de un dreptung$i speci!ic !erestrei abstracte care poate !i mapat& Clasa ?indowing.rans!ormation calculeaza si aplica scala si coe!icientii de translatie pentru obiectele a!isate ca puncte si dreptung$iuri, !ormand a?indow care, trans!ormata, corespunde unui aViewport& Cu toate aceste, trans!ormarea doar scaleaza si modi!ica un set de coordonate, neexistand nicio legatura directa cu a!isarea pe ecranI ast!el, trans!ormarea poate a#ea alta destinatie& ?indowing.rans!ormation poate !i compusa, iar in#ersele sale pot !i in#ocate& View !oloseste trans!ormarile pentru a stabili plasementul subViewului& 3e putem !olosi si daca #rem sa desenam direct o !ereastra& DView displa/.rans!ormE* an)b6ect aplica trans!ormarile a!isa6ului unui receptor catre alt an)b6ect si raspunde rezultatului scalat, translatand obiectul& 5ste des !olosit la D"ectanglesE, DPointsE si alte obiecte ce au coordonatele de!inite in sistemul local de coordonate al View-ului pentru a obtine scalarea si translatarea corecte& View displa/.rans!ormation returneaza ?indowing.rans!ormation care este rezultatul compunerii tuturor trans!ormatelor locale alea retelei de superView-uri cu receptor o trans!ormare locala& View in#erse'ispla/.rans!ormation* aPoint este !olosit de catre controlerul redButtonActi#it/ pentru a con#erti aPoint din coordonatele ecranului in coordonatele !erestrei& VI ! & R SP'(S"BI)I*"*I I( MVC In acest paragra! #om #orbi despre clasa View& View este legat de Model si Controller si este dependent de Model& Clasa abstracta View este supraincarcata prin DmetodeE in SPuea0& 'e !apt, View implementeaza metodele Odispla/, Oupdate, OcontainsPoint si OsubView?antingControl& 'in moti#e nu !oarte intemeiate, View are cea mai mare responsabilitate in DtriadaE MVC& Acesta #a crea si #a atribui un controler si #a adauga si #a elimina dependeta de modelul sau& Suprascrie metoda Ode!aultControllerClass sa raspunda subclasei asociate Controller si atribuie un model !olosind mesa6ul DOmodel*E& 5ste o idee buna sa atribuim o Ddispla/ boxE pentru View& Pentru asta, !olosim DOwindow*E cu argument obiectul Ddreptung$i 7rectangle8E& D"ectangleE
12

este relati# pentru superView, asta insemnand ca, daca redimensionam topView, trebuie sa scalam toate subView-urile& Ast!el, codul ar de#eni !oarte complicat& Putem !ace a!isarea !olosind Odispla/Box 7incluzand c$enarul8 si Oinset'ispla/Box 7imaginea !ara c$enar8& Pentru a atribui un c$enar !olosim Oborder?idt$* sau border?idt$3e!t*rig$t*top*bottom* daca dorim di#erse marimi ale c$enarului& Putem adauga Dwidget-uriE noi !olosind addSubView& Cele mai importante metode View( displa/* desenam ce#a care sa reprezinte D#iew-ulE& 5ste tot timpul desenat pe instanta 'ispla/Screen care ii atribuie o #ariabila globala 'ispla/ 7aceasta metoda nu permite a!isarea mai multor surse in !ereastra principalaI o solutie mai buna este metoda Ddispla/)n* a'ispla/ScreenE8& Implementarea DliberaE deseneaza intai c$enarul 7Odispla/Border8, apoi #iew-ul propriu-zis 7Odispla/View8, la s!arsit desenand sub#iew-urile 7Odispla/SubViews8& 5xista metode ca Oemp$asize si Ode5mp$asize care pot !i !olosite pentru a acti#a DwidgetE sau !ereastra& Aceste metode nu sunt prea bune deoarece, in urma aplicarii lor, !ereastra DpalpaieE pentru ca desenul este a!isat prea des& Dupdate* aS/mbolE* aceasta metoda este apelata cand modelul dependent numeste metoda DOc$angedmet$odE& Putem !olosi metoda pentru a optimiza desenul bazandu-ne pe o stare noua a modelului& DcontainsPoint* aPointE* metoda raspunde cu Dade#aratE daca aPoint !ace parte din View& Putem suprascrie metoda pentru a!isa6e non-rectangulare& 'e exemplu, StandardS/stemView suprascrie aceasta metoda deoarece a !olosit o etic$eta non-rectangulara& R )"*I" VI !-C'(*R')) R In Dsmalltal0-ulE traditional MVC, View si Controller sunt strans legate& iecare instanta a View este asociata cu o instanta unica a Controller-ului 7!iecare instanta a Controller-ului !iind asociata la randul ei cu o instanta unica a View8& Controller-ul este considerat DStrateg/E pe care View il !oloseste ca intrare& View este de asemenea responsabil de crearea a noi View-uri si Controller-e& )bser#atie* Strateg/ este o !amilie de algoritmi incapsulati unul in altul si care e!ectueaza intersc$imbari& In mod logic, daca View si Controller sunt strans legate unul de altul, intrarea si iesirea aplicatiei sa !ie si ele intr-o relatie stransa& In ma6oritatea D!ramewor0-urilorE 4I( MVC, View si Controller !ormeaza un singur obiect&
13

Aceste se numeste D'ocument ViewE& View si Controller sunt DcombinateE in DViewE, iar Model de#ine cunoscut ca D'ocumentE& (n model pasi# comuta responsabilitatile catre controller care trebuie sa anunte #iew-ul cand !ace modi!icari& MVC-ul modern atribuie responsabilitatile DtraditionaleE alea View catre Controller& Aceste de#ine responsabil de crearea si selectarea View-urilor& (neori, responsabilitatile de creare si selectare sunt DdelegateE intr-un obiect speci!ic numit Application Controller sau View 2andler& R )"*I" VI !-M'+ ) View depinde de Model& Sc$imbarile in inter!ata Model-ului cer in paralel sc$imbari in View& 5ste !oarte greu de dobandit o separare stricta intre Model si View& 'e exemplu, consideram cerinta DS$ow negati#e balances in redE& 3a prima #edere aceasta apare a !i o cerere strict legata de iesire, testarea !iind plasata in View ast!el* i! balance Q B t$en red Aceasta poate dauna separarii in MVC& 3a o analiza suplimentara se do#edeste ca cerinta este DS$ow o#erdrawn balances in redE si de!inirea Do#erdrawnE ca Dbalance Q BE trebuie plasata in Model-ul speci!ic& 5ste !oarte usor pentru domeniul logic sa migreze de la Model la View& Bibliografie $ttp*%%st-www&cs&illinois&edu% $ttp*%%www&p$pwact&org% $ttp*%%www&uta&!i%englis$ $ttp*%%wi0i&sPuea0&org $ttp*%%www&mooc0&org $ttp*%%www&wi0ipedia&org%

14

Controller Controllerul este componenta principalR a ar$itecturii MVC, ce conSine logica de execuSie a aplicaSiei& 5l reprezintR atCt punctul de intrare Tn aplicaSie, cCt Ui cel de ieUire Ui se !oloseUte de celelalte componente 7model Ui #iew8 pentru a-Ui Tndeplini sarcina datR& Controllerul este conceptualizat ca o clasR ce poate Tndeplini mai multe !uncSii, numite acSiuni& iecare !uncSie primeUte un set de date de intrare, ce reprezintR parametri sau in!ormaSii date de cRtre utilizator 7datele problemei ce se doreUte a !i soluSionatR8& Aceste date sunt puse cap la cap de cRtre logica internR a controllerului, cu a6utorul claselor model& Vn urma prelucrRrii lor, rezultR datele de ieUire, reprezentCnd soluSia aplicaSiei, date ce sunt trimise unei clase #iew pentru a putea !i trans!ormate Tntr-un !ormat TnSeles de cRtre utilizator& Controllerul este ast!el o cutie neagrR ce acceptR anumite date de intrare, Ui produce Tn urma unor prelucrRri datele de ieUire& Procesarea datelor de intrare Tn cadrul unui controller se !ace prin simpla manipulare a claselor model, ce pun la dispoziSie inter!eSe, adicR metode Ui proprietRSi ce pot !i accesate, utilizate Ui modi!icate din exterior 7de cRtre controller8 !RrR a cunoaUte structura internR a modelului& Ast!el, controllerul lucreazR cu aceste obiecte, modi!icCndu-le Tn modul acceptat de cRtre inter!aSa clasei& 'eUi acest lucru TnseamnR transparenSR totalR, ne!iind ne#oie a se cunoaUte structura internR a clasei respecti#e, apar Ui limitRri legate de imposibilitatea de a accesa date sau a !ace prelucrRri ce nu au !ost pre#Rzute Tn clasa respecti#R& (n exemplu de ast!el de situaSie se poate TntClni atunci cCnd clasele model reprezintR ec$i#alenSe a unor tabele dintr-o bazR de date, Ui se doreUte e!ectuarea unui anumit tip de interogare Tn cadrul controllerului, interogare ce nu a !ost pre#RzutR de model& Principial, controllerul nu are acces direct la baza de date, care este consideratR doar un mod de stocare brut, deci nu poate e!ectua Tn mod direct interogRri& Singura soluSie este implementarea de cRtre model a unei interogRri corespunzRtoare care sR satis!acR cerinSele controllerului&

15

'eUi acest principiu duce la o separare a logicii programului 7aplicaSiei8 Ui !ace mai uUoarR atCt depanarea ulterioarR cCt Ui modi!icarea operaSiilor prin simpli!icarea des!RUurRrii codului 7code !low-ului8, se produce de asemenea Ui o creUtere a dependenSei controller-ului de model, !iind limitat la un set de operaSii pus la dispoziSie de acesta& SituaSia se complicR Ui mai mult atunci cCnd doi sau mai mulSi programatori lucreazR pe secSiuni di!erite de cod& (n programator este specializat Tn baze de date Ui lucreazR cu clasele model, Tn timp ce altul TncearcR sR !acR o aplicaSie ce se !oloseUte de acest model& )rice !acilitate nepre#RzutR de inter!aSa modelului #a trebui implementatR pe loc, ducCnd la o TntCrziere de e!ectuare a programRri pe partea controllerului& Pe de altR parte, programatorul care se ocupR de controllere nu #a trebui sa cunoascR niciun aspect al ar$itecturii bazelor de date spre exemplu, !RcCnd distribuirea !orSei de muncR mult mai !lexibilR& SituaSia Tn cauzR este #alabilR Ui Tn pri#inSa a!iURrii datelor, deci lucrul unui controller cu #iew-urile puse la dispoziSie& View-urile pot !i Tn cazul aplicaSiilor web nimic mai mult decCt template-uri ce de!inesc cum se a!iUeazR datele de ieUire Tn di!erite !ormate 72.M3, "SS etc8& Programatorul care se ocupR de crearea #iew-urilor este de cele mai multe ori un designer web, care nu are cunoUtinSR de ar$itectura internR a aplicaSiei& 5l are acces doar la datele de ieUire, date Tntr-un !ormat anume 71M3, GS)= U&a&m&d8 care sunt inserate Tn spaSii goale din template, creCnd rezultatul 2.M3, interpretat de browserul web Ui #izualizat de cRtre utilizator& Implementarea unui controller (n exemplu de implementare a unui controller Tntr-un !ramewor0 MVC scris Tn Ga#a este prezentat Tn !igura +& Acest controller a!iUeazR mai multe intrRri dintr-o bazR de date& 5l preia de la utilizator ca parametrul numRrul paginii ce se doreUte a!iUatR, apoi #eri!icR dacR datele introduse de cRtre utilizator sunt corecte Ui !ace interogarea clasei model responsabilR de intrRrile solicitate, !olosind metodele puse la dispoziSie de aceasta& 'atele solicitate sunt accesate din obiectul returnat de metoda staticR a modelului, iar rezultatul este a!iUat Tn !ormat 1M3& Se obser#R cR acest controller nu !ace acces direct la baza de date prin intermediul dri#erului ci interog$eazR clasa model& Aceasta returneazR TntrRrile sub !orma de obiecte, ale cRror proprietRSi sunt apoi listate Ui printate Tn documentul 1M3, !olosind clasa #iewer& A!iUarea Tn sine este !Rcuta de #iewer-ul respecti#, nu este responsabilitatea controllerulul& Acesta doar !ace datele disponibile, pentru ca #iewer-ul sR le poatR a!iUa& Codul ast!el rezultat are un numRr de linii redus Ui este uUor de TnSeles%depanat&
16

ig& + Bibliografie +& Patterns o! 5nterprise Application Arc$itecture, Martin owler, 'a#id "ice, Addison ?esle/ 9BB9

17