ModelViewController

Cuprins
Busuioc Andrei - prezentare generala, editare
Context
Problema
Solutia
Istoric
Implementare
Functionare
Variatii
Bibliografie
Constanzo Riccardo - model
Model
Roluri
Comunicare model-view
Bibliografie
Codita Bogdan Alexandru - view
View
Ierarhia view/subview
Afisarea View
Responsabilitati in MVC
Relatia view-controller
Relatia view-model
Bibliografie
Ciuca Alexandru - controller
Controller
Implementare
Bibliografie

Context
In general, scopul multor computere este acela de a prelua informatii dintro anumita locatie, de a o prelucra dupa preferintele utilizatorului si, in cele din
urma, de a o afisa utilizatorului. Dupa ce utilizatorul modifica continutul
informatiei si dupa aplicarea unor eventuale procesari aditionale, sistemul
reinoieste informatia 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. Ulterior apar insa
probleme cand se doreste schimbarea uneia din componentele fluxului de date,
spre exemplu atunci cand se doreste schimbarea interfetei. O alta problema tine
de logica de business ce trebuie incorporata, logica care si ea este supusa
schimbarilor si care merge dincolo de simpla interschimbare de informatie.
Problema
Apare asadar nevoia de a modulariza aplicatia, de a delimita in mod clar
partile componente spre a putea fi usor modificate si ca dupa modificare sa fie
inca compatibile cu celelalte module ce formeaza aplicatia.
Solutia
O solutie la aceasta problema este arhitectura Model-View-Controller
(MVC) care separa partea de stocare a datelor de cea de prezentare si de
prelucrare. Avem 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 exista multiple view-uri pentru un
singur 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 execute operatii pe
baza input-ului primit de la utilizator.

Diagrama arhitecturii MVC prezinta liniile solide ca asocieri directe iar

liniile punctate ca asocieri indirecte.
Istoric
MVC a fost descris pentru prima oara in 1979 de catre Trygve Reenskaug
care pe vremea aceea lucra la Smalltalk din cadrul Xerox PARC. Implementarea
originala este descrisa in detaliu in lucrarea Applications Programming in
Smalltalk-80: How to use ModelViewController.
Implementare
O aplicatie orientata pe principiile MVC poate fi o colectie de triade
model/view/controller, fiecare responsabila de un element diferit al interfetei cu
utilizatorul.
MVC este des intalnit in in aplicatii web unde view-ul este codul HTML
generat de aplicatie. Controller-ul primeste variabile GET si POST ca si input si
decide ce sa faca cu acestea, trimitandu-le mai departe model-ului. Model-ul,
care contine logica de business si regulile aferente, poate efectua operatiile
necesare asupra datelor pentru a putea permite aplicatiei generarea codului
HTMl mai sus mentionat via engine-urile de template, pipeline-uri XML, cereri de
tip Ajax, etc.
Model-ul nu este neaparat doar o baza de date, fiind adesea atat baza de
date cat si logica de business necesara pentru a manipula datele in interiorul
aplicatiei. Multe aplicatii folosesc un mecanism persistent de stocare a datelor.
MVC nu specifica in mod explicit nivel de acces la date tocmai pentru ca este de
la sine inteles ca acesta se afla 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 functionalitatile oferite de aceasta.
3

View-ul, de asemenea nu este limitat doar la afisarea informatiei, el avand

un rol important si in interactiunea cu utilizatorul. In cazul exemplului de mai sus
al aplicatiilor web interfata generata via cod html este cea care se ocupa si de
preluarea input-ului si de masurile luate pentru ca acesta sa fie corect.
Controller-ul este adesea confundat cu aplicatia insasi, pe cand rolul sau
este de a dirija datele intre celelalte doua clase de obiecte. Intr-adevar, se pot
executa multe operatii asupra datelor de catre model, insa aceste operatii tin de
formatul in care se prezinta datele la un moment dat. Adesea se intalneste cazul
in care datele afisate/culese de la utilizator difera semnificativ de cele stocate in
baza de date. Aceste diferente se datoreaza conversiilor ce pot fi aplicate
asupra datelor de catre controller pentru a facilita traficul de informatie intre
componente. Fiecare clasa de obiect are anumite expectative definite in ceea ce
priveste formatul datelor, ori aceste transformari de format trebuie realizate
automat pentru a mentine un flux constant de date, degrevand celelalte clase de
grija conversiilor si asigurand aplicatia ca fiecare modul primeste ceea ce
asteapta. Asta pe langa functia de baza de controla traficul de cereri intre
module.
Functionare
Schema de functionare a unei aplicatii modelate dupa arhitectura MVC
decurge, in linii mari, in felul urmator:
1. Userul interactioneaza cu interfata. (exemplu: apasa un buton la
tastatura)
2. Controller-ul primeste actiunea apasarii butonului si o converteste intr-o
actiune pe intelesul model-ului.
3. Controller-ul notifica model-ul de actiunea utilizatorului, urmand de
obicei o schimbare a starii model-ului. (exemplu: model-ul reimprospateaza
starea campului de adresa)
4. Un view interogheaza model-ul pentru a genera o interfata
corespunzatoare. (exemplu: view-ul afiseaza noua adresa alaturi de cea veche
alaturi de un buton de confirmare)
5. Interfata asteapta actiuni suplimentare din partea utilizatorului, ciclul
reluandu-se.

Variatii
In Application Programming in Smalltalk-80: How to use Model-ViewController (MVC), Steve Burbeck descrie doua variante de MVC: un model pasiv
si un model activ.
Modelul pasiv este folosit
cand un controller manipuleaza
model-ul exclusiv. Controller-ul
modifica model-ul si apoi
informeaza view-ul ca model-ul a
fost schimbat si ca trebuie
reimprospatat. In acest scenariu
model-ul este complet
independent de view si controller,
ceea ce inseamna ca model-ul nu
are cum sa raporteze schimbarile
sale de stare.
Protocolul HTTP este un exemplu
eleocvent al acestui model pasiv.
Browserul nu are cum sa
primeasca update-uri asincrone de la server. Browserul afiseaza view-ul si
raspunde la input utilizator dar nu detecteaza schimbari in datele de pe server.
Doar atunci cand utilizatorul cere in mod explicit o reimprospatare serverul este
interogat pentru eventualele schimbari.
Modelul activ este folosit cand model-ul isi schimba starea fara implicarea
controller-ului. Acest lucru se poate intampla cand alte surse schimba datele iar
schimbarile trebuie reflectate in view-uri.
Un exemplu de astfel de model implementat este banda de stiri in timp real a
canalelor de stiri. Aceasta afiseaza in timp real datele din baza de date pe
masura ce acestea sunt modificate. (pe masura ce noi stiri sunt adaugate)
Totusi, pentru a avea acest model ar insemna ca view-ul sa fie dependent de
model, ori noi dorim ca ambele sa fie independente unul de celalalt.
Introducem notiunea de observator care este un obiect ce notifica celelalte
obiecte de schimbari de stare fara a introduce dependente intre acestea. Viewurile se subscriu la observator pentru a primi notificari. Cand un model se
schimba el notifica toate observatoarele atasate lui de schimbarea produsa. La
randul lor, observatoarele notifica view-urile de schimbarile raportate lor.
Aceasta metoda este cu atat mai eficienta cu cat exista un numar mai mare de
5

modele si view-uri care opereaza dupa modelul dinamic.

Cum model-ul este decuplat
de view via observator.

Functionarea modelului activ pe

baza de notificari trimise prin intermediul
unui observator.

Bibliografie
1. MSDN Library - http://msdn.microsoft.com/en-us/library/ff649643.aspx
2. Wikipedia.org - http://en.wikipedia.org/wiki/Model%E2%80%93View
%E2%80%93Controller

Model
Modelul este inima aplicatiei, partea care nu se schimba. Modelul este
partea ce contine datele, informatiile despre utilizatori. Este, in general,
principalul obiectiv al programatorilor, el constituind marea parte a efortului de
programare. Modelul este cel ce raspunde anumitor comenzi si cel ce comunica
cu baze de date externe.
Model-ul are nevoie de o baza de data unde sa stocheze permanent
datele, care baza de date poate fi incapsulata in model sau poate fi la o anumita
locatie cunoscuta de model. Totusi, in aplicatii mai usoare, model-ul poate fi
confundat cu baza de date insasi, daca operatile pe care le face model-ul sunt
operatii foarte simple.
Intr-o aplicatie creata astfel incat sa respecte acest concept, partea de
model va lucra doar cu starea aplicatiei si cu logica ei, nu va conta cum este sau
va fi reprezentata aceasta stare catre utilizator sau cum interactioneaza acesta
cu aplicatia.
Un alt aspect important este ca atat view-ul, cat si controller-ul depind de
model-ul, in timp ce model-ul nu depinde de ele. Astfel modelul poate fi
implementat si testat fara sa fie nevoie de interfata grafica, dezvoltarea acesteia
facandu-se in paralel.
Model-ul este utilizat la organizarea informatiei si anuntarea cnd aceasta
se modifica. El contine doar date si functionalitati care sunt legate printr-un scop
comun. Daca ar fi fost cazul de a modela date din doua grupuri care nu sunt
legate intre ele, s-ar fi creat doua modele separate. Un model va contine mai
mult decat date si functii care opereaza pe aceste date. Scopul unui model este
de a realiza o aproximare, sau abstractizare, in mediul informational al unor
procese sau sisteme din lumea reala. El nu trebuie sa se limiteze la a captura
starea unui preces sau sistem, ci chiar la cum acel sistem functioneaza, ceea ce
face foarte usoara folosirea modelarii din lumea reala la definirea propriilor
sisteme.

Rolurile partii de model

Partea de model inmagazineaza datele sub forma de proprietati si pune la
dispozitie metode specifice aplicatiei care permit extragerea si fixarea datelor.
Metodele care gestioneaza datele nu sunt ceva generic, ele sunt adaptate
cerintelor aplicatiei si trebuie sa fie cunoscute partilor de control si de vedere.
Datele din cadrul partii de model pot fi modificate 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 vederile sa fie inregistrate sau sa iasa din
evidenta singure, si modelul sa organizeze o lista a vederilor inregistrate. De
fiecare data cnd modelul observa o schimbare importanta a propriei starii,
trebuie sa anunte toate vederile inregistrate. In final, modelul este acela care
implementeaza partea logica a triadei MVC. De asemenea el furnizeaza si
servicii de validare a datelor si alte utilitatii specifice aplicatiei.
Comunicare model - view
In mod normal, modelul nu are nici o informatie in legatura cu view. Totusi
exista o comunicare intre aceste 2 parti si ea are loc daca:
A fost apasat un buton si a fost trimisa o comanda model-ului.
O valoare noua a fost scrisa intr-un text field si un mesaj de actualizare a
fost trimis model-ului.
Daca o valoare este necesara view-ului, o cerere ii este trimisa model-ului
pentru acea valoare.
Astfel, comunicarea are loc daca se intampla un eveniment. View-ul trimite
o cerere catre model care trebuie sa fie capabil sa o descifreze si sa ii trimita un
raspuns, indiferent daca acest raspuns este o valoare sau o serie de operatii
mai complicate. Bineinteles ca este nevoie de o programare buna a modelului
care trebuie sa fie capabil sa descifreze un numar mare de astfel de operatii.
Bibliografie
http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller
http://www.worldit.info/articole/introducere-in-design-patterns-mvc-partea-i/
http://www.securenet.ro/ro/publications/doc/Dezvoltarea_aplicatiilor_web.pdf
http://www.enode.com/x/markup/tutorial/mvc.html
http://msdn.microsoft.com/en-us/library/ff649643.aspx
http://msdn.microsoft.com/en-us/library/ff649643.aspx

VIEW
View este una dintre cele trei componente ale arhitecturii Model-ViewController si are rolul de a atribui Model-ului o forma adecvata pentru
interactiune, de obicei un element de interfata cu utilizatorul. Pot exista mai
multe view-uri pentru acelasi model.
De fiecare data cand este schimbat modelul, fiecare view al modelului este
anuntat ca trebuie sa schimbe reprezentarea vizuala pe ecran. O regiune a
afisajului care nu este in concordanta cu informatia primita de la model se
numeste daunatoare sau invalida. Cand se face o schimbare, view identifica
partea de ecran modificata si o raporteaza la sistemul de ferestre ca fiind
invalida. Acesta confirma zona stricata, urmand sa fie redesenata de catre
view.

In Java putem folosi interfata java.util.Observer ca baza a componentei

view, interfata ce cuprinde subclasa javax.swing.Jpanel.
In urmatorul exemplu, view este implementat in clasa DiagramView.
Implementarea a fost simplificata astfel incat o mica schimbare a modelului
provoaca redesenarea. Acest lucru este realizat in functie de update-ul din
interfata Observer:

public class DiagramView extends Jpanel implements Observer

{
public void update (Observable o, Object arg)
{
if (arg instanceof Diagram.Node)
{
rchace.remove(arg);
}
repaint();
}
}
View decide asupra reprezentarii actuale a diagramei. Singurele lucruri
adaugate conexiunii sunt titlurile si punctul central al nodurilor. View trebuie sa
retina informatiile despre dreptunghiurile de selectie ale nodurilor (harta
structurii de date rcache).
IERARHIA VIEW/SUBVIEW
View-urile sunt construite pentru a fi imbricate. Cele mai multe ferestre
contin doua view-uri, unul imbricat in celalalt. View-ul extern, cunoscut ca
topView, este o instanta a StandardSystemView sau o subclasa a lui.
StandardSystemView gestioneaza fiecare atribut din tabelele ferestrei. In
interiorul topView sunt unul sau mai multe subView-uri care au controlere
asociate ce gestioneaza optiunile de control disponibile pentru fiecare View. De
exemplu, un workspace familiar are StandardSystemView ca topView si
StringHolderView ca subView. Un subView poate avea, optional, alt subView,
dar asta se intampla foarte rar in aplicatii. Relatiile subView/superView sunt
inregistrate in variabile mostenite de la View. Fiecare View are o variabila
superView in care se contine pe sine si contine si alte subView-uri care
reprezinta OrderedCollection pentru subView-uri. Astfel, topView-ul din fereastra
reprezinta varful ierarhiei, urmand apoi variabilele superView si subView.
In continuare voi prezenta un exemplu care contruieste si lanseaza o
triada MVC. Acest exemplu este o versiune simplificata a codului care
deschide methodListBrowser-browser-ul pe care il vedem cand alegem
implementatorii si expeditorii din lista de metode a subView-urilor. SubView-ul
superior afiseaza o lista de metode; cand selectam o metoda, codul sau apare
in subView-ul inferior. In exemplu voi numerota liniile de cod pentru a face
referire mai usor la ele cand le voi explica:

10

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
1.
2.
3.
4.
5-9.
10-13.
14.

openListBrowserOn: aCollection Label: labelString initialSelection:

sel "Create and schedule a Method List browser for the methods in
aCollection."
|topView aBrowser|
aBrowser:=MethodListBrowser new on: aCollection
topView:=BrowserView new.
topView model: aBrowser; controller: StandardSystemController
new;
label: labelString asString; minimumSize: 300@100.
topView addSubView:
(SelectionInListView on: aBrowser printItems: false oneItem: false
aspect: #methodName change: #methodName: list: #methodList
menu: #methodMenu initialSelection: #methodName)
in: (0@0 extent: 1.0@0.25) borderWidth: 1.
topView addSubView:
(CodeView on: aBrowser aspect: #text change: #acceptText:from:
menu: #textMenu initialSelection: sel)
in: (0@0.25 extend: 1@0.75) borderWidth: 1.
topView controller open
Creare model
Creare topView (in general acesta este StandardSystemView, dar in
acest exemplu am folosit BrowserView care este o subclasa a
StandardSystemView)
Specificare model si controler (daca nu specificam controler-ul, el
este furnizat de metoda defaultController cand este prima data
apelat)
Specificare dimensiunea minima pentru topView
Instalare subView superior care este SelectionInListView
Instalare subView inferior
Deschidere controler.

AFISAREA VIEW
View poate avea nevoie de propriul protocol de afisaj care va fi utilizat atat
pentru afisarea imaginii initiale, cat si pentru reafisarea imaginii in cazul unei
schimbari a modelului. Dupa o actualizare a modelului, View trimite propriul
afisaj (self display). View display trimite pe rand self displayBorder, self
displayView, self displaySubviews. Daca View cere o afisare speciala diferita
de cea mostenita, el considera afisarea ca fiind una dintre cele trei enumerate
mai sus. Pentru diverse tehnici de afisare putem cauta implementari in
11

displayView. Observam modificari ale afisajului in functie de fiecare metoda

folosita.
Schimbarile afisajului sunt instante ale WindowingTransformation. Ele
dirijeaza scalarea si translatarea in functie de conexiunea la fereastra si la
porturile View-ului. O fereastra este o intrare a transformarii. Este un dreptunghi
intr-un afisaj abstract avand coordonate arbitrare in sistem, dar apropiate de
nevoile aplicatiei noastre. Un port este reprezentat de un dreptunghi specific
ferestrei abstracte care poate fi mapat. Clasa WindowingTransformation
calculeaza si aplica scala si coeficientii de translatie pentru obiectele afisate ca
puncte si dreptunghiuri, formand aWindow care, transformata, corespunde unui
aViewport. Cu toate aceste, transformarea doar scaleaza si modifica un set de
coordonate, neexistand nicio legatura directa cu afisarea pe ecran; astfel,
transformarea poate avea alta destinatie.
WindowingTransformation poate fi compusa, iar inversele sale pot fi
invocate. View foloseste transformarile pentru a stabili plasementul subViewului. Le putem folosi si daca vrem sa desenam direct o fereastra. View
displayTransform: anObject aplica transformarile afisajului unui receptor catre
alt anObject si raspunde rezultatului scalat, translatand obiectul. Este des folosit
la Rectangles, Points si alte obiecte ce au coordonatele definite in sistemul
local de coordonate al View-ului pentru a obtine scalarea si translatarea corecte.
View displayTransformation returneaza WindowingTransformation care este
rezultatul compunerii tuturor transformatelor locale alea retelei de superView-uri
cu receptor o transformare locala. View inverseDisplayTransformation: aPoint
este folosit de catre controlerul redButtonActivity pentru a converti aPoint din
coordonatele ecranului in coordonatele ferestrei.
VIEW RESPONSABILITATI IN MVC
In acest paragraf vom vorbi despre clasa View. View este legat de Model
si Controller si este dependent de Model. Clasa abstracta View este
supraincarcata prin metode in Squeak. De fapt, View implementeaza metodele
#display, #update, #containsPoint si #subViewWantingControl.
Din motive nu foarte intemeiate, View are cea mai mare responsabilitate in
triada MVC. Acesta va crea si va atribui un controler si va adauga si va elimina
dependeta de modelul sau. Suprascrie metoda #defaultControllerClass sa
raspunda subclasei asociate Controller si atribuie un model folosind mesajul
#model:.
Este o idee buna sa atribuim o display box pentru View. Pentru asta,
folosim #window: cu argument obiectul dreptunghi (rectangle). Rectangle
12

este relativ pentru superView, asta insemnand ca, daca redimensionam

topView, trebuie sa scalam toate subView-urile. Astfel, codul ar deveni foarte
complicat. Putem face afisarea folosind #displayBox (incluzand chenarul) si
#insetDisplayBox (imaginea fara chenar). Pentru a atribui un chenar folosim
#borderWidth: sau borderWidthLeft:right:top:bottom: daca dorim diverse marimi
ale chenarului.
Putem adauga widget-uri noi folosind addSubView.
Cele mai importante metode View:
display: desenam ceva care sa reprezinte view-ul. Este tot timpul
desenat pe instanta DisplayScreen care ii atribuie o variabila globala
Display (aceasta metoda nu permite afisarea mai multor surse in fereastra
principala; o solutie mai buna este metoda displayOn: aDisplayScreen).
Implementarea libera deseneaza intai chenarul (#displayBorder), apoi
view-ul propriu-zis (#displayView), la sfarsit desenand subview-urile
(#displaySubViews). Exista metode ca #emphasize si #deEmphasize care
pot fi folosite pentru a activa widget sau fereastra. Aceste metode nu
sunt prea bune deoarece, in urma aplicarii lor, fereastra palpaie pentru
ca desenul este afisat prea des.
update: aSymbol: aceasta metoda este apelata cand modelul dependent
numeste metoda #changedmethod. Putem folosi metoda pentru a
optimiza desenul bazandu-ne pe o stare noua a modelului.
containsPoint: aPoint: metoda raspunde cu adevarat daca aPoint face
parte din View. Putem suprascrie metoda pentru afisaje non-rectangulare.
De exemplu, StandardSystemView suprascrie aceasta metoda deoarece a
folosit o eticheta non-rectangulara.
RELATIA VIEW-CONTROLLER
In smalltalk-ul traditional MVC, View si Controller sunt strans legate.
Fiecare instanta a View este asociata cu o instanta unica a Controller-ului
(fiecare instanta a Controller-ului fiind asociata la randul ei cu o instanta unica a
View). Controller-ul este considerat Strategy pe care View il foloseste ca
intrare. View este de asemenea responsabil de crearea a noi View-uri si
Controller-e.
Observatie: Strategy este o familie de algoritmi incapsulati unul in altul si care
efectueaza interschimbari.
In mod logic, daca View si Controller sunt strans legate unul de altul,
intrarea si iesirea aplicatiei sa fie si ele intr-o relatie stransa. In majoritatea
framework-urilor GIU MVC, View si Controller formeaza un singur obiect.
13

Aceste se numeste Document View. View si Controller sunt combinate in

View, iar Model devine cunoscut ca Document. Un model pasiv comuta
responsabilitatile catre controller care trebuie sa anunte view-ul cand face
modificari. MVC-ul modern atribuie responsabilitatile traditionale alea View
catre Controller. Aceste devine responsabil de crearea si selectarea View-urilor.
Uneori, responsabilitatile de creare si selectare sunt delegate intr-un
obiect specific numit Application Controller sau View Handler.
RELATIA VIEW-MODEL
View depinde de Model. Schimbarile in interfata Model-ului cer in paralel
schimbari in View. Este foarte greu de dobandit o separare stricta intre Model si
View. De exemplu, consideram cerinta Show negative balances in red. La
prima vedere aceasta apare a fi o cerere strict legata de iesire, testarea fiind
plasata in View astfel:
if balance < 0 then red
Aceasta poate dauna separarii in MVC. La o analiza suplimentara se
dovedeste ca cerinta este Show overdrawn balances in red si definirea
overdrawn ca balance < 0 trebuie plasata in Model-ul specific. Este foarte
usor pentru domeniul logic sa migreze de la Model la View.
Bibliografie

http://st-www.cs.illinois.edu/
http://www.phpwact.org/
http://www.uta.fi/english
http://wiki.squeak.org
http://www.moock.org
http://www.wikipedia.org/

14

Controller
Controllerul este componenta principal a arhitecturii MVC, ce conine
logica de execuie a aplicaiei. El reprezint att punctul de intrare n aplicaie,
ct i cel de ieire i se folosete de celelalte componente (model i view)
pentru a-i ndeplini sarcina dat. Controllerul este conceptualizat ca o clas ce
poate ndeplini mai multe funcii, numite aciuni. Fiecare funcie primete un set
de date de intrare, ce reprezint parametri sau informaii date de ctre utilizator
(datele problemei ce se dorete a fi soluionat). Aceste date sunt puse cap la
cap de ctre logica intern a controllerului, cu ajutorul claselor model. n urma
prelucrrii lor, rezult datele de ieire, reprezentnd soluia aplicaiei, date ce
sunt trimise unei clase view pentru a putea fi transformate ntr-un format neles
de ctre utilizator. Controllerul este astfel o cutie neagr ce accept anumite
date de intrare, i produce n urma unor prelucrri datele de ieire.
Procesarea datelor de intrare n cadrul unui controller se face prin simpla
manipulare a claselor model, ce pun la dispoziie interfee, adic metode i
proprieti ce pot fi accesate, utilizate i modificate din exterior (de ctre
controller) fr a cunoate structura intern a modelului. Astfel, controllerul
lucreaz cu aceste obiecte, modificndu-le n modul acceptat de ctre interfaa
clasei. Dei acest lucru nseamn transparen total, nefiind nevoie a se
cunoate structura intern a clasei respective, apar i limitri legate de
imposibilitatea de a accesa date sau a face prelucrri ce nu au fost prevzute n
clasa respectiv. Un exemplu de astfel de situaie se poate ntlni atunci cnd
clasele model reprezint echivalene a unor tabele dintr-o baz de date, i se
dorete efectuarea unui anumit tip de interogare n cadrul controllerului,
interogare ce nu a fost prevzut de model. Principial, controllerul nu are acces
direct la baza de date, care este considerat doar un mod de stocare brut, deci
nu poate efectua n mod direct interogri. Singura soluie este implementarea de
ctre model a unei interogri corespunztoare care s satisfac cerinele
controllerului.

15

Dei acest principiu duce la o separare a logicii programului (aplicaiei) i

face mai uoar att depanarea ulterioar ct i modificarea operaiilor prin
simplificarea desfurrii codului (code flow-ului), se produce de asemenea i o
cretere a dependenei controller-ului de model, fiind limitat la un set de operaii
pus la dispoziie de acesta. Situaia se complic i mai mult atunci cnd doi sau
mai muli programatori lucreaz pe seciuni diferite de cod. Un programator este
specializat n baze de date i lucreaz cu clasele model, n timp ce altul
ncearc s fac o aplicaie ce se folosete de acest model. Orice facilitate
neprevzut de interfaa modelului va trebui implementat pe loc, ducnd la o
ntrziere de efectuare a programri pe partea controllerului. Pe de alt parte,
programatorul care se ocup de controllere nu va trebui sa cunoasc niciun
aspect al arhitecturii bazelor de date spre exemplu, fcnd distribuirea forei de
munc mult mai flexibil.
Situaia n cauz este valabil i n privina afirii datelor, deci lucrul unui
controller cu view-urile puse la dispoziie. View-urile pot fi n cazul aplicaiilor
web nimic mai mult dect template-uri ce definesc cum se afieaz datele de
ieire n diferite formate (HTML, RSS etc). Programatorul care se ocup de
crearea view-urilor este de cele mai multe ori un designer web, care nu are
cunotin de arhitectura intern a aplicaiei. El are acces doar la datele de
ieire, date ntr-un format anume (XML, JSON .a.m.d) care sunt inserate n
spaii goale din template, crend rezultatul HTML, interpretat de browserul web
i vizualizat de ctre utilizator.
Implementarea unui controller
Un exemplu de implementare a unui controller ntr-un framework MVC
scris n Java este prezentat n figura 1. Acest controller afieaz mai multe
intrri dintr-o baz de date. El preia de la utilizator ca parametrul numrul paginii
ce se dorete afiat, apoi verific dac datele introduse de ctre utilizator sunt
corecte i face interogarea clasei model responsabil de intrrile solicitate,
folosind metodele puse la dispoziie de aceasta. Datele solicitate sunt accesate
din obiectul returnat de metoda static a modelului, iar rezultatul este afiat n
format XML. Se observ c acest controller nu face acces direct la baza de date
prin intermediul driverului ci interogheaz clasa model. Aceasta returneaz
ntrrile sub forma de obiecte, ale cror proprieti sunt apoi listate i printate n
documentul XML, folosind clasa viewer. Afiarea n sine este fcuta de viewer-ul
respectiv, nu este responsabilitatea controllerulul. Acesta doar face datele
disponibile, pentru ca viewer-ul s le poat afia. Codul astfel rezultat are un
numr de linii redus i este uor de neles/depanat.
16

Fig. 1
Bibliografie
1. Patterns of Enterprise Application Architecture, Martin Fowler, David Rice,
Addison Wesley 2002

17