Busuioc Andrei prezentare generala, editare
Yüklə 64,57 Kb.
|
- Bu səhifədəki naviqasiya:
- Comunicare model - view
Model–View–ControllerCuprins
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
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 Model–View–Controller. 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. 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-View-Controller (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. View-urile 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 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 când 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.
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 când 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 - viewIn 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:
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-View-Controller 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(); } }
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: openListBrowserOn: aCollection Label: labelString initialSelection: sel "Create and schedule a Method List browser for the methods in aCollection." |topView aBrowser| 1. aBrowser:=MethodListBrowser new on: aCollection 2. topView:=BrowserView new. 3. topView model: aBrowser; controller: StandardSystemController new; 4. label: labelString asString; minimumSize: 300@100. 5. topView addSubView: 6. (SelectionInListView on: aBrowser printItems: false oneItem: false 7. aspect: #methodName change: #methodName: list: #methodList 8. menu: #methodMenu initialSelection: #methodName) 9. in: (0@0 extent: 1.0@0.25) borderWidth: 1. 10. topView addSubView: 11. (CodeView on: aBrowser aspect: #text change: #acceptText:from: 12. menu: #textMenu initialSelection: sel) 13. in: (0@0.25 extend: 1@0.75) borderWidth: 1. 14. topView controller open 1. Creare model 2. Creare topView (in general acesta este StandardSystemView, dar in acest exemplu am folosit BrowserView care este o subclasa a StandardSystemView) 3. Specificare model si controler (daca nu specificam controler-ul, el este furnizat de metoda defaultController cand este prima data apelat) 4. Specificare dimensiunea minima pentru topView 5-9. Instalare subView superior care este SelectionInListView 10-13. Instalare subView inferior 14. 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 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 subView-ului. 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” 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:
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. 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.
Controller Controllerul este componenta principală a arhitecturii MVC, ce conţine logica de execuţie a aplicaţiei. El reprezintă atât punctul de intrare în aplicaţie, cât şi cel de ieşire şi se foloseşte de celelalte componente (model şi view) pentru a-şi îndeplini sarcina dată. Controllerul este conceptualizat ca o clasă ce poate îndeplini mai multe funcţii, numite acţiuni. Fiecare funcţie primeşte un set de date de intrare, ce reprezintă parametri sau informaţii date de către utilizator (datele problemei ce se doreşte a fi soluţionată). Aceste date sunt puse cap la cap de către logica internă a controllerului, cu ajutorul claselor model. În urma prelucrării lor, rezultă datele de ieşire, reprezentând soluţia aplicaţiei, date ce sunt trimise unei clase view pentru a putea fi transformate într-un format înţeles de către utilizator. Controllerul este astfel o cutie neagră ce acceptă anumite date de intrare, şi produce în urma unor prelucrări datele de ieşire. Procesarea datelor de intrare în cadrul unui controller se face prin simpla manipulare a claselor model, ce pun la dispoziţie interfeţe, adică metode şi proprietăţi ce pot fi accesate, utilizate şi modificate din exterior (de către controller) fără a cunoaşte structura internă a modelului. Astfel, controllerul lucrează cu aceste obiecte, modificându-le în modul acceptat de către interfaţa clasei. Deşi acest lucru înseamnă transparenţă totală, nefiind nevoie a se cunoaşte structura internă a clasei respective, apar şi limitări legate de imposibilitatea de a accesa date sau a face prelucrări ce nu au fost prevăzute în clasa respectivă. Un exemplu de astfel de situaţie se poate întâlni atunci când clasele model reprezintă echivalenţe a unor tabele dintr-o bază de date, şi se doreşte efectuarea unui anumit tip de interogare în cadrul controllerului, interogare ce nu a fost prevăzută 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 interogări. Singura soluţie este implementarea de către model a unei interogări corespunzătoare care să satisfacă cerinţele controllerului. Deşi acest principiu duce la o separare a logicii programului (aplicaţiei) şi face mai uşoară atât depanarea ulterioară cât şi modificarea operaţiilor prin simplificarea desfăşurării codului (code flow-ului), se produce de asemenea şi o creştere a dependenţei controller-ului de model, fiind limitat la un set de operaţii pus la dispoziţie de acesta. Situaţia se complică şi mai mult atunci când doi sau mai mulţi programatori lucrează pe secţiuni diferite de cod. Un programator este specializat în baze de date şi lucrează cu clasele model, în timp ce altul încearcă să facă o aplicaţie ce se foloseşte de acest model. Orice facilitate neprevăzută de interfaţa modelului va trebui implementată pe loc, ducând la o întârziere de efectuare a programări 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, făcând distribuirea forţei de muncă mult mai flexibilă. Situaţia în cauză este valabilă şi în privinţa afişării datelor, deci lucrul unui controller cu view-urile puse la dispoziţie. View-urile pot fi în cazul aplicaţiilor web nimic mai mult decât template-uri ce definesc cum se afişează datele de ieşire î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 cunoştinţă de arhitectura internă a aplicaţiei. El are acces doar la datele de ieşire, date într-un format anume (XML, JSON ş.a.m.d) care sunt inserate în spaţii goale din template, creând rezultatul HTML, interpretat de browserul web şi vizualizat de către 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 afişează mai multe intrări dintr-o bază de date. El preia de la utilizator ca parametrul numărul paginii ce se doreşte afişată, apoi verifică dacă datele introduse de către utilizator sunt corecte şi face interogarea clasei model responsabilă de intrările solicitate, folosind metodele puse la dispoziţie de aceasta. Datele solicitate sunt accesate din obiectul returnat de metoda statică a modelului, iar rezultatul este afişat î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ă întrările sub forma de obiecte, ale căror proprietăţi sunt apoi listate şi printate în documentul XML, folosind clasa viewer. Afişarea în sine este făcuta de viewer-ul respectiv, nu este responsabilitatea controllerulul. Acesta doar face datele disponibile, pentru ca viewer-ul să le poată afişa. Codul astfel rezultat are un număr de linii redus şi este uşor de înţeles/depanat.  Fig. 1
Bibliografie 1. Patterns of Enterprise Application Architecture, Martin Fowler, David Rice, Addison Wesley 2002 Yüklə 64,57 Kb. Dostları ilə paylaş:
|