J2EE (Java 2 Enterprise Edition) este o platforma Java proiectata pentru a prelucra date pentru organizatii mari, care folosesc mainfraime - uri. Sun Microsystems (împreuna cu partenerii sai ca IBM) au proiectat J2EE pentru a simplifica dezvoltarea aplicatiilor client/server cu client, fara capacitate mare de procesare (ca de exemplu un browser). J2EE simplifica dezvoltarea aplicatiilor prin crearea de componente care pot beneficia de multe servicii din partea platformei în mod automat.
Platforma J2EE pune la dispozitie un model multi tier distribuit de realizare a aplicatiilor. Aceasta înseamna ca parti diferite ale aplicatiei pot sa ruleze pe calculatoare diferite. Arhitectura J2EE defineste un Client Tier , un Middle Tier (care poate fi compus din mai multe subtiers, de obicei denumite Web Tier si EJB Tier) si un Enterprise Information Tier care furnizeaza servicii utilizând sistemele de informatii deja existente (de obicei bazele de date).
Client tier suporta o mare varietate de tipuri de clienti care se pot afla sau nu dupa firewall, cum e cazul, in general, al firmelor care se protejeaza folosind firewalls.
Middle tier furnizeaza servicii pe de o parte pentru clienti folosind containere Web si pe de alta parte pentru componentele de business folosind containere Enterprise JavaBeans.
Enterprise Information System furnizeaza accesul la sistemele informationale deja existente, folosind APIs (Application Programming Interfaces) standardizate.
În Figura 2.3., se prezinta arhitectura generica a unei 919f59j aplicatii enterprise folosind J2EE, cu ilustrarea împartirii în tiers (straturi).
Figura 2.3. Arhitectura multi tier pusa la dispozitie de platforma J2EE
Platforma Java 2 Enterprise Edition este compusa dintr-o suita de tehnologii care fac platforma usor de utilizat, chiar pentru probleme complicate, astfel dându-i o valoare sporita.
Nucleul tehnologiei J2EE este Enterprise JavaBeans (EJB), care este o specificatie a componentelor software utilizate de catre platforma J2EE. Aceasta specificatie este implementata de mai multe firme (prima care a reusit a fost BEA prin produsul WEBLogic).
Celelalte tehnologii utilizate de platforma J2EE vor fi prezentate foarte pe scurt în continuare:
Java Remote Method Invocation (RMI) si RMI- IIOP. Tehnologia RMI permite comunicarea între procese si furnizeaza alte servicii legate de comunicare. RMI-IIOP este o extensie portabila a RMI, care foloseste protocolul de comunicare Internet Inter Object Protocol (IIOP). IIOP poate fi utilizat pentru a migra spre CORBA (Common Object Request Broker). Folosind CORBA, se poate realiza comunicarea între aplicatii de pe platforme diferite, scrise în limbaje de programare diferite. Aceasta este o modalitate de legare a componentelor J2EE cu alte componente create folosind alte tehnologii.
Java Naming and Directory Interface (JNDI). JNDI identifica locatia componentelor si a altor resurse în retea.
Java Database Connectivity (JDBC). JDBC este un bridge (punte de legatura) care permite realizarea unor operatii la baza de date în mod portabil.
Java Transaction API (JTA) si Java Transaction Serice (JTS). Aceste tehnologii adauga platformei J2EE capacitatea de a rula tranzactii la nivel de componente software si la nivelul bazei de date.
Java Messaging Service (JMS). JMS permite comunicarea între obiecte distribuite în mod asincron.
Java Servlets si Java Server Pages (JSP). Servlet-urile si JSP - urile sunt componente de retea care sunt potrivite pentru prelucrari cerere / raspuns, cum este cazul clientilor HTTP.
Java IDL este implementarea standardului CORBA de catre Sun folosind Java. Java IDL permite obiectelor distribuite sa beneficieze de toate serviciile puse la dispozitie de catre CORBA. De remarcat ca platforma J2EE este complet compatibila CORBA.
Java Mail este un serviciu care permite aplicatiilor sa trimita mesaje e-mail într-o maniera independenta de platforma, respectiv de protocol.
Connectors. Conectorii sunt o tehnologie care permite integrarea unor sisteme deja existente.
Extensible Markup Language (XML). Unele tehnologii J2EE (ca EJB1.1 si JSP) utilizeaza XML pentru a descrie continutul.
În Figura 2.4., este prezentata o imagine de ansamblu a tuturor tehnologiilor care sunt parte din J2EE si care fac aceasta platforma foarte puternica.
Având în vedere importanta majora a acestor tehnologii ca parti ale platformei J2EE, se va face, în continuare, o prezentare foarte sumara a fiecareia.
Figura 2.4. Imagine de ansamblu asupra tehnologiilor utilizate de platforma J2EE
RMI este un mecanism de invocare a metodelor obiectelor aflate pe alte statii sau pe aceeasi statie, dar în Java Virtual Machine diferite . Este foarte bine integrata cu limbajul Java. RMI permite programatorilor Java sa comunice într-o maniera distribuita, folosind un stil de programare aproape identic cu cel de la scrierea applet-urilor sau a aplicatiilor stand alone. RMI aduce comunicarea prin retea la nivelul de concept deorece ascunde programatorului detaliile legate de retea, ca de exemplu ordinea de transmitere a bitilor. RMI are si alte caracteristici, ca de exemplu download - ul dinamic de clase, activarea automata a obiectelor distante. Are un Garbage Collector distribuit, care distruge obiectele distante nefolosite.
Aceasta tehnologie este un standard pentru serviciile de naming and directory. Enterprise JavaBeans se bazeaza pe aceasta tehnologie pentru a gasi componentele distribuite în retea. JNDI este o tehnologie cheie, deoarece aceasta este singura modalitate de a obtine o referinta la componente din codul clientului.
Figura 2.5. Serviciul de naming and directory JNDI
JNDI afiseaza termenul de serviciu de directoare. Un serviciu de directoare stocheaza informatii despre locul în care se afla componentele, cât si alte informatii conexe, ca de exemplu numele utilizatorului si parola. În EJB, atunci când un client cere accesul la o componenta, serviciul de directoare este folosit pentru a obtine o componenta care sa deserveasca acel client. Serviciul de directoare poate fi gândit ca facând corespondenta între clienti si componentele cerute.
În mod istoric, exista mai multe asemenea servicii de directoare, ca de exemplu NDS de la Novell sau LDAP. JNDI este independent de toate acestea, fiind ca o punte care stie sa comunice cu toate aceste servicii. JNDI abstractizeaza codul scris într-un serviciu de naming and directory particular si permite ca sa se foloseasca alt serviciu fara a modifica codul. Din acest motiv, folosind JNDI se poate scrie cod portabil pentru serviciul de naming and directory.
Package-ul Java Database Connectivity (JDBC 2.0) este o extensie standard a limbajului Java, care permite programatorilor Java sa foloseasca o unica interfata aplicatie (API) pentru accesul la baze de date relationale. Cu JDBC, programatorii Java pot folosi conexiuni la baze de date, executa comenzi SQL, procesa rezultatele interogarilor, utiliza proceduri stocate si multe altele, într-o maniera portabila. Pentru fiecare tip de baza de date care se doreste a fi utilizata împreuna cu JDBC, este nevoie de un driver care "traduce" comenzile JDBC în comenzi specifice acelei baze de date. JDBC este asemanator cu Open Database Connectivity (ODBC), ba chiar cele doua sunt inter-operabile prin puntea JDBC - ODBC.
JDBC 2.0 are, din start, inclus
mecanismul de pooling pentru
conexiunile la baze de date. Este un lucru stiut ca o conexiune la o
baza de date este mare consumatoare de resurse. Acest mecanism permite ca
o anumita conexiune sa fie utilizata mai eficient. Atunci când o
componenta are nevoie de o conexiune se va instantia una. Cand
componenta nu o mai utilizeaza conexiunea este trecuta într-un
asa numit bazin (pool) . În
momentul când vreo componenta are nevoie de o conexiune, se va scoate din
bazin conexiunea si se va furniza componentei pentru a o utiliza.
Numarul de conexiuni maxim din bazin este configurabil.
Figura 2.6. Privire de ansamblu asupra JDBC
Datorita importantei mari in aplicatii, aceasta tehnologie va fi tratata separat într-un capitol urmator.
O tranzactie este un set de operatii care sunt garantate ca vor fi executate împreuna, iar daca apar erori, atunci se renunta la toate operatiile din succesiunea de operatii ce au fost deja executate. Tranzactiile sunt unul dintre punctele forte ale platformei J2EE. Rolul lor este de a mentine un sistem în stare de consistenta. Tranzactiile permit mai multor utilizatori sa modifice aceleasi date simultan si, totusi, tranzactiile sa fie izolate unele de altele . În esenta, este o forma foarte avansata de sincronizare a datelor.
Pentru a facilita tranzactiile, firma Sun a produs doua interfete aplicatie : Java Transactions API (JTA) si Java Transaction Service(JTS). Aceste doua produse specifica cum pot fi realizate tranzactiile în Java, dupa cum se poate observa din Figura 2.7.
JTA este o interfata de nivel înalt, care permite aplicatiilor client sa controleze tranzactiile în codul Java.
JTS este un set de interfete de nivel jos pentru tranzactii, care este folosit de catre EJB în spatele scenelor. JTS este bazat pe Object Transaction Service (OTS), care este o parte a CORBA. Enterprise JavaBeans depinde strict de JTA, dar nu depinde de JTS.
Figura 2.7. Java Transaction API (JTA) si Java Transaction Service (JTS)
Un serviciu de messaging permite obiectelor distribuite sa comunice într-o maniera asincrona, dar sigura. Prin faptul ca mesajele sunt trimise asincron, în loc sa fie transmise sincron, scalabilitatea sistemului creste. Procesele pot raspunde la mesaje când sunt în executie, dar exista situatia în care s-ar putea sa nu se afle în executie în momentul în care mesajul este trimis initial.
Specificatia Java Messaging Service (JMS) defineste un serviciu portabil de messaging. Prin utilizarea unui API comun, obiectele distribuite pot comunica într-o maniera tranzactionala, toleranta la caderi, asincrona, dar cel mai important este ca ele comunica într-o maniera independenta de vendor. În Figura 2.8. este schitat serviciul de messaging din platforma J2EE.
Figura 2.8. Serviciul de messaging JMS al platformei J2EE
Servlet - urile sunt componente distribuite, care pot fi folosite pentru a extinde functionalitatea unui server Web. Servlet - urile sunt orientate pe un protocol de tipul cerere / raspuns, în sensul ca preiau cererile de la clientii care le lanseaza (de obicei dintr-un Web browser), iar apoi proceseaza un raspuns pentru acea cerere. Din acest motiv, servlet-urile sunt potrivite pentru a rezolva problemele legate de Web. Oricum, este important de observat faptul ca servlet-urile nu sunt, în mod necesar, legate de serverele Web si pot fi utilizate ca si componente generice de tipul cerere / raspuns, fara a necesita managementul sofisticat al unui application server.
Java Server Pages (JSPs) sunt foarte similare servlet-urilor. De fapt, scripturile JSP sunt compilate în servlet-uri. Cea mai mare diferenta dintre scripturile JSP si servlet-uri este ca scripturile JSP nu sunt cod Java pur, ci sunt centrate mai mult în jurul problemelor de aspect ale interfetei. Se vor utiliza pagini JSP atunci când se doreste ca partea de interfata a aplicatiei sa fie separata de restul aplicatiei. Avantajul paginilor JSP este ca pot fi realizate si întretinute de catre persoane care nu cunosc programare în Java.
Ambele tehnologii vor fi prezentate într-un subcapitol separat datorita faptului ca sunt foarte des utilizate.
CORBA este un standard dezvoltat de catre OMG în interesul si cu acordul comun a sute de alte companii care au fost interesate într-o arhitectura independenta de platforma. CORBA este independent de limbaj. Nu conteaza limbajul în care este scris programul, atâta timp cât CORBA suporta acel limbaj.
Common Object Request Broker Architecture (CORBA) defineste o arhitectura pentru crearea, distribuirea si managementul obiectelor distribuite într-o retea. Aceasta arhitectura permite programelor din locatii diferite si dezvoltate în limbaje de programare diferite sa comunice în retea prin intermediul unui Object Request Broker (ORB). Acest ORB reprezinta programul care actioneaza ca "broker" între cererile pentru un anume serviciu, venite de la un obiect sau componenta distribuita si satisfacerea acelor cereri. Daca într-o retea este implementat ORB, atunci componentele sau obiectele pot solicita servicii de la alte componente de pe alte masini, fara a fi nevoie sa stie nici macar pe ce server sunt situate acele componente distante sau cum arata interfata la server. Prin intermediul ORB, componentele pot sa se gaseasca una pe alta si sa schimbe informatii în timpul rularii.
Un ORB foloseste CORBA Interface Repository pentru a localiza în retea o componenta si pentru a comunica cu ea. Atunci când se creeaza o componenta care sa poata utiliza serviciile puse la dispozitie de ORB, programatorul trebuie sa declare interfetele publice ale componentei folosind Interface Definition Language (IDL).
IDL este un limbaj care permite unui obiect scris într-un limbaj sa comunice cu un alt obiect scris într-un limbaj "necunoscut". IDL solicita ca interfetele unui program sa fie descrise într-un stub, care este o extensie adaugata programului si compilata împreuna cu el. Stubs din fiecare program sunt utilizate de catre ORB pentru a realiza comunicarea între componente. De exemplu, când o componenta este solicitata sa furnizeze un serviciu de catre ORB, stub accepta cererea de la ORB si o da componentei propriu-zise, care, dupa ce o onoreaza, returneaza rezultatele stub - ului, care le trimite apoi înspre ORB. Astfel, prin intermediul stub-urilor, se realizeaza comunicarea cu ORB, iar prin intermediul ORB, se realizeaza comunicarea în retea.
Este foarte important ca ORB sa fie implementat în acel limbaj. Java IDL este implementarea specificatiei CORBA pentru limbajul Java si permite conectarea si inter-activitatea cu obiecte heterogene. Java IDL este o implementare specifica a CORBA. Exista mai multe asemenea implementari ale CORBA în limbajul Java. Desi Java IDL nu implementeaza tot ceea ce specifica standardul CORBA, el este furnizat gratis împreuna cu platforma J2EE.
Java Mail API permite aplicatiilor sa trimita email - uri. La fel ca alte API din J2EE, Java Mail defineste un set de interfete care vor fi utilizate pentru a scrie aplicatii, folosind serviciile de mail. Aceste interfete sunt o abstractizare a serviciului de mail, astfel încât codul aplicatiei sa nu depinda de o anume implementare a serviciului de mail. Deci codul scris folosind API - ul de JavaMail este portabil atât privitor la platforme, cât si la protocoale.
XML este un standard universal de structurare a continutului electronic în documente. XML este extensibil în sensul ca, spre deosebire de HTML, tag-urile sunt nelimitate si se autodefinesc. XML este o varianta mai simpla si mai usor de utilizat a Standard Generalized Markup Language (SGML), standardadul utilizat pentru a crea structura documentelor. Standardul XML nu este afectat de problema revizuirii standardului de la o versiune la alta, deoarece nu exista tag -uri predefinite, dimpotriva tag-urile se definesc dupa nevoie. Cu alte cuvinte, XML este o metoda flexibila de definire a formatului informatiilor si de distribuire a formatului împreuna cu datele.
Platforma J2EE foloseste XML în mai multe feluri. JSP foloseste XML pentru a specifica formatul paginilor si continutul lor. XML este, de asemenea, utilizat în specificatia EJB1.1. pentru descrierea datelor utilizate la deployment-ul aplicatiilor.
J2EE include package-ul Java API for XML Processing (JAXP), care permite procesarea documentelor XML prin intermediul DOM, SAX si XSLT.
Simple API for XML (SAX) poate fi gândit ca un protocol de acces serial la XML. Acesta este un mecanism rapid, care consuma putina memorie. Acest protocol este event-driven (condus de evenimente), pentru ca tehnica este de a înregistra un handler cu un parser SAX, iar apoi parserul va invoca metodele înregistrate ori de câte ori întâlneste un nou tag de acel tip (sau întâmpina o eroare). Deci specific pentru SAX este ca tag - urile se parcurg unul dupa altul, în mod serial, fara a putea avea acces oricând la orice parte din date.
Document Object Model (DOM) se deosebeste de SAX prin aceea ca DOM converteste documentul XML într-o colectie de obiecte în cadrul programului. Acest model de obiecte poate fi manipulat în toate felurile care au vreo semnificatie. Acest mecanism este denumit random access protocol pentru ca se poate accesa orice parte din date în orice moment. Datele se pot modifica, sterge sau pot fi inserate date noi.
Comparând cele doua API se poate afirma ca SAX consuma mai putine resurse decât DOM, însa nu permite accesul în orice moment la oricare parte a datelor, asa cum permite DOM.
Extensible Stylesheet Language for Transformations (XSLT) este, în esenta, un mecanism de traducere care permite specificarea modului în care sa fie tradus un tag XML. Ca de exemplu, cum sa fie tradus un tag XML în HTML pentru a putea fi apoi afisat. Apoi se pot utiliza diferite formate XSL pentru a afisa aceleasi date în moduri diferite pentru utilizatori diferiti.
Modelul de programare J2EE permite o proiectare a aplicatiilor care sa fie scalabile, sa permita re-utilizarea componentelor. Modelul de programare J2EE are în miezul sau integrarea straturilor (tiers).
În Figura 2.9., este prezentata o posibila arhitectura de complexitate maxima, care poate fi suportata de catre aplicatiile J2EE. Se observa ca exista posibilitatea utilizarii mai multor Web Containers si EJB Containers, ceea ce face ca aplicatiile J2EE sa fie foarte scalabile.
Figura 2.9. Arhitectura de complexitate maxima a unei aplicatii J2EE
Prin eliminarea unor parti din arhitectura de maxima complexitate, se obtin alte noi arhitecturi care pot fi adecvate pentru aplicatii particulare.
Figura 2.10. ilustreaza un scenariu de aplicatie în care containerul Web gazduieste componente Web dedicate, aproape în exclusivitate, pentru a realiza logica de prezentare. Furnizarea continutului dinamic Web spre client este responsabilitatea paginilor JSP si a servlet -urilor. Containerul EJB gazduieste componentele aplicatie care, pe de-o parte, raspund cererilor din Web Tier, iar pe de alta parte, acceseaza resursele Enterprise Information System. Puterea acestui scenariu sta în capacitatea de a decupla accesarea datelor de partea care realizeaza interactiunea cu clientul. Aceasta face ca aplicatia sa fie usor de modificat ulterior.
Figura 2.10. Scenariul multi tier al unei aplicatii J2EE
Trebuie mentionat ca XML este parte integranta a acestui scenariu. Avantajul major al acestui fapt este ca se adauga facilitatea de a produce si consuma mesaje XML în containerul Web. Aceasta este o metoda foarte flexibila de a trimite si primi mesaje de la mai multe tipuri de platforme. Aceste platforme pot varia de la obisnuitele XML enabled browsers la cele mai specializate rendering engines (motoare de afisare) care folosesc XML. Indiferent de domeniul aplicatiei, se considera ca datele XML vor utiliza HTTP pentru comunicare.
Apare aparenta dilema de a utiliza pagini JSP sau servlet -uri. Programarea J2EE promoveaza tehnologia JSP ca o facilitate a containerului Web. Paginile JSP se bazeaza pe functionalitatea servlet-urilor, dar modelul de programare J2EE afirma ca paginile JSP sunt mai naturale, mai usor de utilizat si realizat de catre programatorii Web. Deci Web containerul este optimizat pentru crearea continutului dinamic destinat clientilor Web, asa ca, în mod normal, se for utiliza pagini JSP si doar în mod exceptional servlet-uri.
Privind din perspectiva modelului de programare J2EE, se impune considerarea a trei tipuri de clienti stand alone:
Clienti EJB care inter actioneaza direct cu serverul EJB, de fapt cu Enterprise JavaBeans gazduite de containerul EJB. Un asemenea scenariu este ilustrat în Figura 2.11. Aici se presupune ca se utilizeaza RMI - IIOP pentru accesul la EJBs. Pentru accesul la resursele întreprinderii (de obicei baze de date), se utilizeaza JDBC, iar în viitor se vor utiliza conectorii.
Figura 2.11. Client Java care interactioneaza direct cu EJB components
Clienti sub forma de aplicatii Java stand alone care acceseaza direct resursele întreprinderii (de obicei baze de date) folosind JDBC. În acest scenariu, logica de prezentare si logica de business sunt, prin definitie, puse pe platforma clientului si sunt integrate într-o aceeasi aplicatie. Acest scenariu elimina middle tier. De fapt, în esenta, acest scenariu este foarte asemanator cu cel al unei aplicatii client - server. Din pacate, el mosteneste si toate neajunsurile acestei arhitecturi legate de distributie, întretinere si scalabilitate.
Clienti Visual Basic care consuma continutul dinamic Web cel mai adesea sub forma de mesaje XML. În acest scenariu, containerul Web are, în principal, rolul de a trece datele sub forma de masaje XML pe care mai apoi le trimite clientilor. Logica de prezentare este lasata în seama client tier. Web Tier poate fi proiectat sa contina logica de business si sa acceseze direct bazele de date. Ideal ar fi ca logica de business sa fie totusi plasata în serverul EJB, unde s-ar putea descrie mult mai bine modelul.
Acest scenariu este ilustrat în Figura 2.12. În acest caz, Web containerul gazduieste, în esenta, atât logica de prezentare, cât si logica de business. Trebuie mentionat ca în unele implementari J2EE, cum este cea de referinta de la Sun, s-a ales sa se implementeze serverul J2EE, astfel încât cele doua containere( Web containerul si EJB containerul) sa fie integrate împreuna. Din aceasta rezulta o comunicare eficienta între cele doua containere. În acest caz, se poate considera, totusi, ca aplicatia este multi tier.
Figura 2.12. Scenariul unei aplicatii centrata în Web tier
Acest scenariu se focalizeaza pe interactiuni directe între containere. Modelul de programare J2EE propune utilizarea XML pentru a transmite mesaje utilizând protocolul HTTP ca metoda primara pentru a realiza comunicarea între Web containere. Aceasta comunicare se doreste sa fie cât mai putin "cuplata", în sensul de restrictiva. Acest scenariu este foarte potrivit pentru aplicatiile Web de comert electronic.
Figura 2.13. Scenariul Business to Business
Aplicatiile J2EE, indiferent de scenariul pe care îl urmeaza, pot fi realizate folosind arhitectura Model View Controller (MVC). Aceasta permite realizarea unor aplicatii care sa fie scalabile si usor de modificat si dezvoltat în continuare. Aceasta se realizeaza, in principal, datorita faptului ca se permite componentelor sa fie cât mai independente unele de altele.
Arhitectura MVC este un design pattern (tipar de proiectare) care permite divizarea functionalitatii obiectelor implicate în prezentarea datelor cu un grad de cuplaj (dependenta) cât mai mic. Aceasta arhitectura a fost initial conceputa pentru a prezenta datele în interfetele grafice standard. Aceste concepte sunt usor de mapat si în domeniul aplicatiilor enterprise multi tier bazate pe interfata Web.
În arhitectura MVC, partea de Model reprezinta datele aplicatiei si regulile care guverneaza accesul si modificarea acestor date. De cele mai multe ori, modelul reprezinta o aproximatie software a proceselor din lumea reala.
Modelul notifica partea de View atunci când apar schimbari si pune la dispozitia acestuia metode de interogare asupra starii modelului. El pune, de asemenea, la dispozitia partii de controller metode de a accesa functionalitatile aplicatiei, care vor modifica apoi datele încapsulate de catre model. Cu alte cuvinte, controller - ul nu are acces direct la datele încapsulate de Model, ci doar prin API - ul pus la dispozitie de acesta.
Partea de View afiseaza datele încapsulate de model. El acceseaza datele din model si specifica cum vor fi prezentate. Atunci când datele din model se modifica, este responsabilitatea modelului de a mentine consistenta prezentarii. Gesturile utilizatorului sunt trimise la controller.
Un controller defineste comportarea aplicatiei. El interpreteaza gesturile utilizatorului si le transpune apoi în actiuni pe care le va executa modelul. Pentru un client de tipul interfata grafica sub forma de aplicatie stand alone, gesturile utilizatorului ar putea fi selectie de meniuri si clickuri. Pentru aplicatiile Web, ele apar ca si cereri de tipul GET sau POST adresate Web Tier. Actiunile realizate de catre controller presupun inclusiv activarea proceselor de business sau schimbarea starii modelului. Bazat pe gesturile utilizatorului si pe rezultatul comenzilor date modelului, controller-ul va selecta un view pe care îl va trimite ca raspuns pentru cererea primita. Pentru fiecare set de functionalitati, exista, de obicei, câte un controller. De exemplu, pentru aplicatiile destinate managementului resurselor umane, exista un controller pentru angajati si un altul pentru personalul de resurse umane.
Interactiunile dintre Model View si Controller sunt aratate în Figura 2.14.
Figura 2.14. Interactiunile între Model View si Controller în cadrul unei aplicatii care respecta design patternul Model View Controller
|
