Model-View-Controller

Context

Scopul multor sisteme informatice este de a prelua date de la un magazin de date i s le afieze
pentru utilizator. Dup ce utilizatorul schimb datele, sistemul stocheaz actualizrile n depozitul
de date. Deoarece fluxul cheie de informaii ntre depozitul de date i interfaa cu utilizatorul, ai
putea dori s legi aceste dou piese mpreun pentru a reduce cantitatea de codificare i pentru a
mbunti performana aplicaiilor. Totui, aceast abordare aparent natural are unele
probleme semnificative. Una dintre probleme este c interfaa cu utilizatorul tinde s se schimbe
mult mai frecvent dect sistemul de stocare a datelor. O alt problem cu cuplarea pieselor de
date i a interfeei cu utilizatorul este c aplicaiile business au tendina de a ncorpora logica de
business, care merge dincolo de transmiterea datelor.

Problem
Cum putei modulariza funcionalitatea interfeei unei aplicaii Web, astfel nct s putei
modifica cu uurin piesele individuale?
Fore
Urmtoarele fore acioneaz asupra unui sistem n acest context i trebuie s fie mpacate n
timp ce se ia n considerare o soluie la problema:
- Logica interfeei cu utilizatorul tinde s se schimbe mai frecvent dect logica de afaceri, n
special n aplicaiile bazate pe Web. De exemplu, se pot aduga pagini noi de interfa cu
utilizatorul, sau anumite aspecte de pagin existente pot fi rearanjate. La urma urmei, unul dintre
avantajele unei aplicaii thin-client bazate pe Web este faptul c putei schimba interfaa cu
utilizatorul n orice moment, fr a redistribui aplicaia. n cazul n care codul de prezentare i
logica de afaceri sunt combinate ntr-un singur obiect, trebuie s modificai un obiect care
conine logica de afaceri de fiecare dat cnd schimbai interfaa cu utilizatorul. Acest lucru
poate s introduc erori i necesit retestarea intregii logici de afaceri dup fiecare schimbare
minim a interfaei cu utilizatorul.
- n unele cazuri, aplicaia va afia aceleai date n moduri diferite. De exemplu, atunci cnd un

analist prefer s vad o foaie de calcul n timp ce de managementul prefer o diagram radial
cu aceleai date. In unele interfee utilizator cu muli clieni, mai multe moduri de vizualizare
ale acelorai date sunt afiate concomitent. Dac utilizatorul schimb datele ntr-un singur punct
de vizualizare, sistemul trebuie s actualizeze n mod automat toate celelalte vizualizri ale
datelor.

- Proiectare de pagini HTML atrgtoare vizual i eficiente necesit un set diferit de competene
dect dezvoltarea unei logici complexe de afaceri. Rareori o persoan are ambele seturi de
calificri. De aceea, este de dorit s se separe efortul de dezvoltare a acestor dou pri.

- Activitatea interfaei de utilizator const, n general, n dou pri: prezentare i actualizare.

Partea de prezentare preia date de la o surs de date i le formateaz pentru afiare. Atunci cnd
utilizatorul efectueaz o aciune asupra datelor, partea de actualizare cedeaz controlul napoi la
logica de business pentru a actualiza datele.

- n aplicaii Web, un singur request al unei pagini combin procesarea aciunii asociate cu linkul pe care utilizatorul l-a selectat cu redarea paginii int. n multe cazuri, pagina destinaie nu
poate fi direct legat de aciune. De exemplu, imaginai-v o aplicaie Web simpl care afieaz
o list de elemente. Utilizatorul se ntoarce la pagina principal de listare, fie dup adugarea
unui element n list sau dup tergerea unui element din list. Prin urmare, cererea trebuie s
afieze aceeai pagin (list) dup executarea a dou comenzi destul de diferite (adugarea sau
tergerea) - toate n aceeai cerere HTTP.

- Codul interfa cu utilizatorul tinde s fie mai dependent de dispozitiv dect de logica de
business. Dac dorii s portai cererea dintr-o aplicaie bazat pe browser pe PDA-uri sau
telefoane care suporta browsing, trebuie s nlocuii o mare parte din codul de interfa cu
utilizatorul, ntruct logica de business poate fi afectat. O separare clar a acestor dou pri
accelereaz portarea i minimizeaz riscul introducerii de erori n logica de business.
- Crearea de teste automate pentru interfee de utilizatori este, n general, mai dificil i
consumatoare de timp dect cele pentru logica de business. Prin urmare, reducerea cantitii de
cod legat direct la interfaa de utilizator mbuntete posibilitatea de testare a aplicaiei.

Soluie
Modelul Model-View-Controller (MVC) separ modelarea domeniului, prezentarea i aciunile
bazate pe date introduse de utilizator n trei clase separate [Burbeck92]:

Model. Modelul gestioneaz comportamentul i datele domeniului aplicaiei, rspunde

solicitrilor de informaii cu privire la starea sa (de obicei, de la View), i rspunde
instruciunilor de schimbare a strii (venite, de obicei, de la operator).

View. Vizualizarea gestioneaz afiarea informaiilor.

Controller. Controllerul interpreteaz intrrile de la mouse i tastatur, informnd modelul

i/sau vizualizarea pentru a modifica n mod corespunztor.
Figura 1 prezint relaia structural dintre cele trei obiecte:

Figura 1: Structura clasei MVC

Este important s reinei c att vizualizarea, ct i controllerul depind de model. Cu toate

acestea, modelul nu depinde nici de vizualizare, nici de controller. Acesta este unul din
principalele avantaje ale separrii. Aceast separare permite modelului s fie construit i testat
independent de vizualizare. Separarea dintre vizualizare i controller este secundar n multe
aplicaii cu muli clieni, i, de fapt, mai multe cadre de interfa cu utilizatorul pun n aplicare
rolurile ca un singur obiect. n aplicaii Web, pe de alt parte, separarea ntre vizualizare
(browser) i controller (componentele pe partea de server de manipulare a cererii HTTP) este
foarte bine definit.

Model-View-Controller este un model de design fundamental pentru separarea logicii de

interfa cu utilizatorul, de logica de business. Din pcate, popularitatea modelului a dus la o
serie de descrieri defecte. n special, termenul de "controller" a fost folosit pentru a nelege
lucruri diferite n contexte diferite. Din fericire, apariia aplicaiilor web a ajutat la rezolvarea a
o parte din ambiguitilor, deoarece separarea ntre vizualizare i controller este att de evident.

Variaii
n Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC)
[Burbeck92], Steve Burbeck descrie dou variante ale MVC: un model pasiv i un model activ.
Modelul pasiv este folosit cnd un controller manipuleaz exclusiv modelul. Controllerul
modific modelul i vizualizarea informeaz apoi c modelul s-a schimbat i ar trebui s fie
actualizat (a se vedea figura 2). Modelul, n acest scenariu, este complet independent de
vizualizarea i controller, ceea ce nseamn c nu exist mijloace pentru model de a raporta
schimbri n starea sa. Protocolul HTTP este un exemplu n acest sens. Nu exist nici o
modalitate simpl pentru browser pentru a obine actualizri asincrone de pe server. Browser-ul
afieaz vederea i rspunde la datele introduse de utilizator, dar nu detecteaz schimbri n
datele de pe server. Numai atunci cnd utilizatorul solicit n mod explicit refresh, serverul este
interogat pentru modificri.

Figura 2 : Comportamentul modelului pasiv

Modelul activ este utilizat atunci cnd modificrile asupra modelului au fost facute fr
implicarea controllerului. Acest lucru se poate ntmpla atunci cnd alte surse se schimb datele
i modificrile trebuie s se reflecte n vizualizare. Luai n considerare un ecran de bursier.
Primii date de stoc de la o surs extern i dorii s actualizai vizualizrile (de exemplu, un
ticker-band i o fereastr de alert), cnd se modific datele de stoc. Deoarece numai modelul
detecteaz modificri la starea sa intern cand acestea apar, modelul trebuie s notifice
vizualizrile pentru a actualiza ecranul.

Cu toate acestea, una dintre motivaiile folosind modelul MVC ca modelul s fie independent de
vizualizare. Dac modelul ar fi trebuit s notifice vizualizrile modificrilor, ar reintroduce
dependena pe care vrei sa o evii. Din fericire, modelul Observer [Gamma95] prevede un
mecanism pentru a alerta alte obiecte de modificrile strii, fr a introduce dependen de ele.
Punctele de vedere individuale implementeaz interfaa Observer i registrul cu modelul.
Modelul urmrete lista observatorilor care subscriu la schimbri. Atunci cnd un model sufer
modificri, modelul itereaz prin toi observatorii nregistrai i le notific schimbarea. Adesea,
aceasta abordare este numit " abonare public". Modelul nu necesit informaii specifice
despre vizualizri. De fapt, n scenariile n care controllerul trebuie s fie informat cu privire la
modificrile modelului (de exemplu, pentru a activa sau dezactiva opiunile de meniu), tot
trebuie s fac controllerul este s pun n aplicare interfaa Observer i s se aboneze la
modificrile modelului. n situaiile n care exist multe vizualizri, este logic s se defineasc
mai multe subiecte, fiecare descriind un anumit tip de schimbare de model. Fiecare vizualizare se
poate abona atunci numai la tipurile de modificri care sunt relevante pentru vizualizare.
Figura 3 prezint structura activ MVC folosind Observer i cum observatorul izoleaz modelul
de referire direct a vizualizrii.

Figura 3 : Folosirea Observer pentru decuplarea modelului de vizualizare n modelul activ

Figura 4 ilustreaz modul n care Observer notific vizualizrile de modificrile modelului. Din
pcate, nu exist nici o modalitate bun de a demonstra separarea modelului i a vizualizrii

ntr-o diagram secvenial Unified Modeling Language (UML), pentru c schema reprezint
mai degrab instane de obiecte, dect clase i interfee.

Figura 4 : Comportamenul modelului activ

Consideraii de testare
Testabilitatea este mult mbuntit cnd se folosete Model-View-Controller. Testarea
componentelor devine dificil atunci cnd acestea sunt foarte interdependente, n special cu
componentele interfa de utilizator. Aceste tipuri de componente necesit adesea un setup
complex doar pentru a testa o funcie simpl. Mai ru, cnd apare o eroare, este greu s izolezi
problema la o anumit component. Acesta este motivul pentru care separarea de preocupri este
un driver arhitectural att de important. MVC separ preocuparea de stocare, afiare i
actualizare a datelor n trei componente care pot fi testate individual.

n afar de problemele ridicate de interdependene, cadre interfa cu utilizatorul sunt n mod

inerent dificil de testat. Testarea de interfee necesit fie testri manuale plictisitoare
(i predispuse la erori) , fie testnd scripturi care simuleaz aciunile utilizatorului. Aceste
script-uri tind s fie fragile i consumatoare de timp pentru dezvoltare. MVC nu elimina nevoia
pentru a testa interfaa cu utilizatorul, dar separarea modelului de logic de prezentare permite ca
modelul s fie testat independent de prezentare i interfaa cu utilizatorul reduce numrul de
cazuri de testare.

Contextul Rezultat

Construind nivelul prezentare n jurul rezultatelor modelului MVC rezult n urmtoarele

beneficii i responsabiliti:

Beneficii
Suport mai multe vizualizri. Deoarece vizualizarea este separat de model i nu exist nici o
dependen direct ntre modelul i vizualizarea, interfaa cu utilizatorul poate afia mai multe
vizualizri ale acelorai date n acelai timp. De exemplu, mai multe pagini ntr-o aplicaie web
pot folosi aceleai obiecte de model. Un alt exemplu este o aplicaie Web care permite
utilizatorului schimbarea aspectului paginilor. Aceste pagini afieaz aceleai date de la modelul
comun, dar arat ntr-un mod diferit.
Poate gzdui schimbri. Cerine interfeei utilizator tind s se schimbe mai rapid dect regulile
de business. Utilizatorii pot prefera culori diferite, fonturi, machete de ecran, i niveluri de
suport pentru noi dispozitive, cum ar fi telefoanele mobile sau PDA-uri. Deoarece modelul nu
depinde de vizualizri, adugarea a noi tipuri de vizualizri la sistemul general nu afecteaz
modelul. Drept urmare, domeniul de aplicare al schimbrii se limiteaz la vizualizare. Acest
model pune bazele pentru mai multe specializri de la acest model, cum ar fi Page Controller i
Front Controller.

Responsabiliti
Complexitate. Modelul MVC introduce un nou nivel de ocolire i, drept urmare, crete uor i
complexitatea soluiei. Acesta crete, de asemenea, natura concentrata pe evenimente din codul
interfeei utilizator, care poate deveni mai dificil de depanat.
Costul actualizrilor frecvente. Decuplarea modelului de vizualizare nu nseamn c
dezvoltatorii modelului pot ignora natura vizualizrilor. De exemplu, n cazul n care modelul
sufer schimbri frecvente, ar putea inunda vizualizrile cu cereri de actualizare. Unele
vizualizri, cum ar fi afiaje grafice, pot dura mai mult. Ca urmare, vizualizrile pot cdea
ntrzia fa de cererile de actualizare. Prin urmare, este important s se in cont de vizualizare
la codarea modelului. De exemplu, modelul ar putea grupa mai multe actualizri ntr-o singur
notificare la vizualizare.
Variante
Varianta Document-View recunoate toate cele trei roluri din Model-View-Controller, dar mbin

controllerul n vizualizare. Documentul corespunde rolului pe care l are modelul n MVC.

Aceast variant este prezent n mai multe platforme GUI existente. Un exemplu excelent de
Document-View este clasa Microsoft Foundation Class Library (MFC) n mediul Microsoft
Visual C ++. Compromisul folosirii aceastei variante este cuplajul mai strns dintre vizualizare
i controller
.
Modele nrudite relevante
Pentru mai multe informaii, consultai urmtoarele modele asociate:
Observer. Acest model este adesea coroborat cu MVC datorita necesitii de a menine
sincronizarea dintre vizualizare i modelul asociat.
Page Controller i Front Controller. Acest model descrie strategiile de punere n aplicare
pentru partea controlerului de model MVC.

Mulumiri
Model-View-Controller a inceput ca un cadru dezvoltat de Trygve Reenskaug pentru platforma
Smalltalk la sfritul anilor 1970 [Fowler03]. Versiunea pe care ai citit-o face referine
urmtoarele lucrri:
[Burbeck92] Burbeck, Steve. "Application Programming in Smalltalk-80: How to use ModelView-Controller (MVC)."University of Illinois in Urbana-Champaign (UIUC) Smalltalk
Archive. Available at: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html.
[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley,
2003.
[Gamma95] Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, 1995.