FOLOSIND JAVA ȘI SPRING FRAMEWORK Îndrumător științific: Asist.univ.dr. Irina Tudor Absolvent: Drozd Ana -Maria CRAIOVA – 2017 – 3 Cuprins CAPITOLUL… [605392]

1

UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE ȘTIINȚE
SPECIALIZAREA INFORMATICĂ

LUCRARE DE LICENȚĂ

Îndrumător științific:
Asist.univ.dr. Irina Tudor
Absolvent: [anonimizat]-Maria Drozd

CRAIOVA
– 2017 –

2
UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE ȘTIINȚE
SPECIALIZAREA INFORMATICĂ

DEZVOLTAREA APLICAȚIILOR WEB
FOLOSIND JAVA ȘI SPRING FRAMEWORK

Îndrumător științific:
Asist.univ.dr. Irina Tudor
Absolvent: [anonimizat] 2017 –

3
Cuprins
CAPITOLUL 1 – INTRODUCERE ÎN DEZVOLTAREA APLICAȚIILOR WEB ………………………….. ……………………… 4
1.1 Ce Este O Aplicație Web? ………………………….. ………………………….. ………………………….. ……………….. 4
1.2 Cum Funcționează O Aplicație Web? ………………………….. ………………………….. ………………………….. .. 5
CAPITOLUL 2 – DEZVOLTAREA APLICAȚIILOR WEB CU JAVA EE ………………………….. ………………………….. ….. 7
2.1. Introducere În Platformă De Programare Java Enterprise Edition ………………………….. ………………… 7
2.2. Servleturi ………………………….. ………………………….. ………………………….. ………………………….. ………… 9
2.2.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. .. 9
2.2.2 Capabilitățile se rvleturilor ………………………….. ………………………….. ………………………….. ……… 10
2.2.3 Avantajele servleturilor ………………………….. ………………………….. ………………………….. …………. 10
2.2.4 Manipularea cererilor făcute de utilizatori ………………………….. ………………………….. …………… 11
2.2.5 Anatomia unui servlet HTTP ………………………….. ………………………….. ………………………….. ……. 11
2.2.6 Arhitectura pachetelor javax.servlet și javax.servlet.http ………………………….. ……………………. 12
2.2.7 Interacțiunea cu clienții ………………………….. ………………………….. ………………………….. …………. 13
2.3. Pagini Jsp ………………………….. ………………………….. ………………………….. ………………………….. ………. 13
2.3.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. 13
2.3.2 Ce este JSP? ………………………….. ………………………….. ………………………….. …………………………. 14
2.3.3 Structura unei pagini JSP ………………………….. ………………………….. ………………………….. ……….. 17
CAPITOLUL 3 – DEZVOLTAREA APLICAȚIILOR WE B ÎN SPRING ………………………….. ………………………….. ….. 19
3.1 Prezentare Generală A Framework -Ului Spring ………………………….. ………………………….. ……………. 19
3.2 Arhitectura Spring ………………………….. ………………………….. ………………………….. ……………………….. 20
3.3 Inversiunea De Control Prin Spring Framework (Ioc) Și Injectarea Dependențelor …………………….. 22
3.3.1 Dependențele între obiecte ………………………….. ………………………….. ………………………….. ……. 22
3.3.2 Abordarea Spring asupra dependențelor între obiecte ………………………….. ……………………….. 23
3.3.3 Inversion of Control vs Dependency Injection ………………………….. ………………………….. ……….. 25
3.4 Spring Mvc ………………………….. ………………………….. ………………………….. ………………………….. ……… 26
CAPITOLUL 4 -TEHNICI DE MAPARE OBIECTUAL -RELATIONALE (ORM) CU JPA ȘI HIBERNATE ………………. 28
4.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. …….. 28
4.1.1 Configurarea bean -ului SessionFactory în containerul Spring ………………………….. ……………… 29
4.1.2 Configurarea entităților JPA ………………………….. ………………………….. ………………………….. ……. 29
CAPITOTUL 5 – DESCRIEREA APLICAȚIEI ȘI A TEHNOLOGIILOR FOLOSITE ÎN CONTEXTUL DAT ………………. 32
5.1 Tehnologiile Și Uneltele Folosite ………………………….. ………………………….. ………………………….. ……. 32
5.2 Cazuri De Utilizare (Use Cases) ………………………….. ………………………….. ………………………….. ………. 33
5.3 Configurarea Mediului Spring ………………………….. ………………………….. ………………………….. ………… 42
5.4 Separare a Codului În Mai Multe Straturi În Funcție De Responsabilități ………………………….. ………. 45
5.5 Arhitectura bazei de date ………………………….. ………………………….. ………………………….. ……………… 47
5.6 Design Pattern -Uri Implementate De Spring Și Folosite În Aplicația TennisStars ……………………….. 48
5.6.1 Injectarea dependetelor (Dependency Injection Pattern) ………………………….. ……………………. 48
5.6.2 Pattern -ul Front Controller în Spring ………………………….. ………………………….. …………………….. 49
5.6.3 Pattern -ul MVC – Model View Controller ………………………….. ………………………….. ………………. 49
5.6.4 Pattern -ul Factory ………………………….. ………………………….. ………………………….. ………………….. 50
5.6.5 Pattern -ul Singleton în Spring și Java ………………………….. ………………………….. ……………………. 51
BIBLIOGRAFIE ………………………….. ………………………….. ………………………. Error! Bookmark not defined.

4
CAPITOLUL 1 – INTRODUCERE ÎN DEZVOLTAREA
APLICAȚIILOR WEB

1.1 Ce Este O Aplicație Web?

O ap licație Web este o aplicație accesibilă dintr -un browser web și aflată pe un alt
calculator, numit server, fiind altul decât calculatorul folosit de utilizator (sau “client” al
aplicației), ambele fiind conectate în rețeaua Internet. Comunicarea între prog ramele de navigare
pe Internet (Mozilla FireFox, Internet Explorer, Opera, Chrome) și aplicația de pe server se face
prin protocolul HTTP și limbajul HTML. Această comunicare între calculatorul server și
calculatorul client a dus la denumirea de client -server application. (Oracle, 2013)
Serverul Web primește cereri HTTP de la clienți (browsere) și trimite răspunsuri sub
forma unor pagini Web care conțin documente HTML și alte resurse asociate (imagini,
videoclipuri etc.). La început, conținutul unui răsp uns era static (simple fișiere HTML pregătite
anterior și redate ca atare), însă odată cu dezvoltarea tehnologiei web, răspunsurile au devenit
dinamice (pe lângă fragmente HTML, mai conțin o serie de servicii suplimentare și un
“container” în care se execu tă aplicațiile, ca de exemplu requestul către baza de date).
Clientul (utilizatorul) unei aplicații Web introduce în browser adresa unei resurse Web,
numită URL (Uniform Resource Location) adică un nume de locație, de “site”, de aceea se
folosește uneo ri și expresia “site” sau “website” în loc de aplicație. De exemplu,
http://www.host.com/path/file.html. Termenul “host” desemnează calculatorul server din rețeaua
Internet care “găzduiește” aplicația Web, iar “path” este calea (secvența de directoare) din server
către fișierul “file.html”. În general, după introducerea adresei de site de către clientul aplicației,
aplicația din server trimite o pagină de prezentare (“home page”), care permite utilizatorului
selectarea unor operații prevăzute de aplicație s au care cere acestuia informații de identificare
(ușer și parolă), în cazul în care aplicația are restricții de acces. În continuare, dialogul client –
server are loc prin cereri HTTP formulate de client prin intermediul unor elemente de interfață
grafică (b utoane, căsuțe pentru introducere text, formulare s.a.), la care aplicația trimite ca
răspuns pagini web (HTML) ce pot conține text, imagini, alte formulare și date extrase din baze
de date, existente pe server.
Aplicațiile Web oferă următoarele avantaje :
• oferă acces oricărui calculator legat la Internet iar modificarea aplicației se face prin
modificări în server, fără a afecta utilizatorii aplicației.

5
• programul browser nu necesită multe resurse, de aici expresia “thin client” pentru
utilizatorul unui browser.
• sistemul de operare(Windows, Linux sau altul) sub care se execută programul browser,
nu contează dar pot conta eventuale diferențe de implementare a standardelor Web (HTML, CSS,
DOM, Javascript) de către browser.

1.2 Cum Funcționează O Aplicație Web?

Orice aplicație Web trebuie să interpreteze cererile HTTP primite de la browser (GET,
POST, s.a.) și să genereze pagini Web ca răspuns la aceste cereri. În plus, cele mai multe aplicații
folosesc și una sau câteva baze de d ate din care se extrag date ca urmare a unor cereri, iar aceste
date sunt incluse în paginile de răspuns (pagini cu conținut dinamic). (Falkner & Jones, 2004)
Fiecare aplicație are o anumită logică (un algoritm) de tratare a cererilor primite, logică car e
poate deveni destul de complexă.
Aplicațiile Web au în general o complexitate mai mare decât aplicațiile locale pentru că:
-Problemele care trebuie rezolvate presupun competențe diferite și limbaje diferite: HTML și
JavaScript pentru partea de prezent are, baze de date și SQL pentru datele persistente și un limbaj
de programare (de obicei orientat pe obiecte) pentru logică aplicației.
-Trebuie compatibilizate limbaje și tehnologii diferite: cererile HTTP trebuie transformate în
obiecte, paginile HTML t rebuie să preia date din programe Java; aceste limbaje nu au fost
proiectate să lucreze împreună. Probleme similare apar la utilizarea datelor dintr -o bază de date
relațională într -un limbaj cu obiecte, ceea ce a condus la apariția unor produse de tip ORM
(Object Relațional Mapping) pentru rezolvarea lor.
-Protocolul HTTP este un protocol “stateless”, în care o cerere nu ține seamă de cererile
anterioare (de “starea” aplicației), dar în practică multe aplicații Web funcționează că un automat
cu stări (de e x. Acumularea unor comenzi de produse într -un coș de cumpărături).
-Accesul public la aplicațiile Web și numărul mare de utilizatori ridica probleme de securizare și
de calitate a serviciilor (disponibilitate permanență, modificare continuă).
-Testarea ș i depanarea aplicațiilor Web sunt mai dificile decât pentru aplicațiile locale.
-Cerințele asupra acestor aplicații au crescut continuu atât că facilități oferite (poștă electronică,
servicii Web, portaluri, s.a), ca aspect (componente grafice de interfaț ă cât mai diverse), ca
ușurință de utilizare de către beneficiarii (interactivitate sporită) aplicației și ca timp de
implementare.

6
Ca orice aplicație software reală și aplicațiile Web au o evoluție în timp, în sensul că se
pot modifica cerințele privin d interfață de acces și funcționalitatea aplicației. De aceea contează
nu numai timpul de dezvoltare a unui prototip inițial al aplicației ci și efortul de modificare a
aplicației aflată în exploatare.
Soluțiile pentru abordarea acestei complexități au diverse forme:
-Modularizarea (componentizarea) aplicațiilor Web prin folosirea schemei de proiectare MVC
-Utilizarea de platforme suport (Web Frameworks) pentru dezvoltarea și testarea aplicațiilor
-Utilizarea de medii IDE cu facilități speciale pen tru aplicații Web (Eclipse, NetBeans, IDEA,
s.a.).
-Folosirea unor limbaje mai noi (Python, Ruby, Groovy, Scala) și modernizarea limbajelor mai
vechi cu tehnici OOP (PHP 5, JavaScript, s.a.) pentru reducerea codului aplicațiilor.
Tehnologiile folosite p entru realizarea de aplicații Web au evoluat rapid iar în prezent există o
mare diversitate de soluții disponibile, clasificate în general după limbajele utilizate în partea de
server: PHP, Perl, Python, Ruby s.a.

7
CAPITOLUL 2 – DEZVOLTAREA APLICAȚIILOR WEB CU
JA V A EE

2.1. Introducere În Platformă De Programare Java Enterprise Edition

Platforma Java, Enterprise Edition sau Java EE este o platformă de calcul utilizată pe
scară largă pentru dezvoltarea și implementarea sof turilor enterprise, adesea numită aplicație de
firmă (Enterprise Application) pentru că apare în firmele mari informatizate. Java EE a fost
cunoscută inițial ca Java 2 Platform, Enterprise Edition sau J2EE. (Oracle, 2013)
Platforma utilizează limbajul de p rogramare Java orientat pe obiect. Face parte din
familia de platforme software Java. Java EE extinde Platforma Java, Ediția Standard (Java SE),
[2] oferind un API pentru maparea obiect -relațională, arhitecturi distribuite și multitier și servicii
web. Pla tforma încorporează un design bazat, în mare parte, pe componente modulare care
rulează pe un server de aplicații. Platforma pune accent pe convenție și folosirea adnotărilor
pentru configurație. Opțional, XML poate fi utilizat pentru a suprascrie adnotări le sau pentru a se
abate de la valorile implicite ale platformei.Java EE este dezvoltat în cadrul Java Community
Process.
Java EE este în primul rând o colecție de specificații care ar trebui respectate de serverele
compatibile JEE (SPI=System Programm er Interface) și respectiv de aplicațiile JEE
(API=Application Programmer Interface). (Oracle, 2013)
Specificațiile se referă la:
-interfețe API și biblioteci de clase care să unifice programarea aplicațiilor distribuite complexe:
JDBC pentru acces la b aze de date SQL, JMS pentru mesagerie, JNDI pentru registre de nume,
JAX-WS și JAX -RS pentru servicii Web, JTA pentru tranzacții, JPA pentru persistență, etc.
-componente “standard” ale aplicațiilor Web: servleti, pagini JSP, biblioteci de tag -uri, module
EJB (Enterprise Java Beans), portleti, conectori, etc.
-servicii care trebuie asigurate de către un server de aplicații (un container de aplicații Web).
-fișiere de configurare și structură arhivelor ce conțin aplicații Web.
Ideea principală era de a reduce diversitatea aplicațiilor Web scrise în Java și diversitatea
serverelor de aplicații Java pentru a reduce timpul de dezvoltare și de instalare pe diferite servere
a unor aplicații, inclusiv prin reutilizarea unor module și servicii comune.
Unele dintre tehnologiile introduse de JEE pentru aplicații Web scrise în Java se folosesc
și în servere sau produse framework care nu sunt total compatibile JEE: servleti, JSP, logging,

8
s.a.
Un server care suportă aplicații Web scrise în Java trebuie să c onțină un container de
servleti. Principalele servere compatibile Java sunt Apache Tomcat și Jetty.
Un server de aplicații (AȘ=Application Server) oferă servicii suplimentare față de un
server container de servleti (pe care -l conține): tranzacții, jur nalizare (logging), servicii de nume,
s.a. Acesta expune clienților posibilitatea de a utiliza aplicații aflate pe un alt calculator și
implementează toate interfețele API de pe platformă JEE și oferă serviciile considerate standard
pentru toate aplicații le. În present, există mai multe servere de aplicații compatibile Java EE,
unele comerciale (IBM Websphere, JBoss, Weblogic) și altele gratuite ( Glassfish, Geronimo
s.a.).
Platformă JEE este destinată în primul rând aplicațiilor mari și admite o d iversitate a
acestor aplicații, în sensul că pot exista mai multe servere, că utilizatorul final (client) poate
folosi și alte programe decât un browser Web, că poate fi necesară integrarea în aplicația JEE a
unor baze de date sau fișiere existențe anterio r.
Aplicații le JEE au și atributul de “multi -tiered” adică sunt structurate pe mai multe
niveluri, iar tehnologiile folosite sunt clasificate după nivelul pe care se folosesc. Cele 3 niveluri
sunt:
-Nivelul Web (Web Tier) : partea care preia cererile client și le transmite nivelului următor.
-Nivelul Business (Business Tier): partea de logică a aplicației, care compune răspunsuri
-Nivelul EIS (Enterprise Information System): partea de lucru cu date persistente (externe).
Tehnologiile JEE folosi te pe nivelul Web sunt:
-Servleti
-JSP (Java Server Pages) și biblioteci de taguri JSP (JSP Tag Library)
-JSF (Java Server Faces)
-JSF Facelets
-Limbajul unificat de expresii (Unified Expression Language)
-Clase JavaBeans folosite în paginile JSP și JSF
Tehnologiile JEE folosite pe nivelul Business sunt:
-Componente EJB (Enterprise Java Beans)
-Servicii Web de tip REST
-Furnizori/clienți de servicii Web SOAP
-Entități persistente JPA (Java persistence API)
Tehnologiile JEE folosite pe n ivelul EIS sunt:
-JDBC (Java Data Base Connectivity) care integrează limbajul SQL în Java

9
-JPA (Java Persistence API)
-Java EE Connector Architecture, pentru cuplare cu produse non -JEE
-JTA (Java Transaction API) pentru utilizare de tranzacții

2.2. Servleturi
2.2.1 Introducere
WEB -ul a trecut în ultimii ani printr -o transformare rapidă. Paginile HTML statice au fost
schimbate cu pagini dinamice. Informația conținută în paginile dinamice poate fi văzută, de
exemplu, precum conținutul unei maga zii cu stocul în continuă schimbare.
Pentru a înțelege mai bine ce este un servlet, vom prezenta în paralel și noțiunea de
applet. Un applet Java este o clasă Java care se execută pe JVM -ul clientului (printr -un plug -in
de browser). Un servlet Java se exe cută pe partea de server într -un container Servlet, ca Apache
Tomcat, iar clientul primește rezultatele sub forma unui simplu HTML. Diferența esențială este
că atunci când unul rulează pe partea clientului, celălalt pe partea serverului. Servleturile sunt
programe care rulează pe servere WEB, fiind poziționate între cererile care vin de la browser sau
de la un client HTTP și bazele de date sau aplicații de pe serverul de HTTP. (Falkner & Jones,
2004)
Un servlet reprezintă o componentă web, gestionată de un container, care generează
conținut dinamic. Servlet -urile rulează pe server și sunt clase Java, ce oferă independență de
platformă și sunt încărcate și executate dinamic de către server. Servlet -urile comunică cu clienții
pe baza paradigmei cerere – răspun s. Acest model cerere – răspuns se bazează de obicei pe
protocolul Hypertext Transport Protocol (HTTP).
Containerul de servleturi este o componentă ce oferă servicii de rețea prin intermediul
cărora servleturile primesc și transmit cereri și răspunsuri de la și către clienți. Containerul de
servleturi înmagazinează servleturile și este responsabil pentru gestionarea acestora. Un
container poate exista în cadrul unui server web sau poate fi adăugat ulterior utilizând
mecanismul de extensie al serverului.
Putem exemplifica și mai bine ce este un servlet, printr -un exemplu concret: un program
client (web browser) accesează un server web și transmite o cerere HTTP (poate fi de exemplu
un form completat cu date despre o persoană). Această cerere este preluată de către serverul web
și este transmisă mai departe către containerul de servleturi. Acesta determină cărui servlet îi este
adresată cererea și invocă respectivul servlet, transmițându -i ca parametri două obiecte: cerere
(request) și răspuns (response). Servl etul va utiliza obiectul request pentru a determina cererea

10
făcută de clientul web. După realizarea operațiilor necesare, precum scrierea sau citirea unor date
dintr -o bază de date, servletul va transmite către client un ră spuns prin obiectului response.
2.2.2 Capabilitățile servleturilor
Principalele capabilități ale servlet -urilor sunt: (Falkner & Jones, 2004)
1. pot citi datele trimise de ușeri: aceste date sunt, de obicei, introduse într -un
formular WEB sau pot proveni dintr -un applet Java sau de la un p rogram client de
HTTP;
2. pot formata rezultatele într -un document: în cele mai multe cazuri, aceasta implică
inserarea informației într -o pagină HTML;
3. pot seta parametrii HTTP de răspuns: se informează browser -ul ce tip de
document este returnat (HTML, de ex emplu), se setează “cookies” etc.
4. trimit documentul înapoi la client: documentul poate fi trimis în format Text
(HTML), în format binar (imagini GÂF), sau chiar în format compresat.
Servlet -urile nu sunt restricționate numai la WEB sau aplicații server car e manipulează
cereri HTTP; de asemenea pot fi folosite și pentru alte tipuri de servere. De exemplu, servlet –
urile pot fi insera te în servere de email sau FTP.
2.2.3 Avantajele servleturilor
1. Eficiența
În cazul servlet -urilor, mașina virtuală Java rămân e în execuție și fiecare cerere este
rezolvată printr -un thread. Există N thread -uri, dar o singură copie a clasei servlet. Servleturile
rămân în memorie chiar și după ce răspunsul a fost complet.
2. Securitatea
Pe lângă eficiență servleturile mai au o car acteristică importantă, securitatea. Firele de
execuție sunt create de către mașina virtuală Java și posedă toate facilitățiile oferite de aceasta
din punctul de vedere al securității.
3. Puterea
Servlet -urile pot comunica direct cu serverul WEB. Mai mult e servlet -uri pot împărți
date, făcând mult mai ușoară conectarea cu baza de date.
4. Portabilitate
Servlet -urile sunt scrise în Java și pot rula pe servere ca Apache, Microsoft Internet
Information Server (IIS), IBM WebSphere sau StarNine WebStar, fără vr eo schimabare a
codului. Servlet -urile sunt parte din Jav a Platform Enterprise Edition.

11
2.2.4 Manipularea cererilor făcute de utilizatori
Una dintre motivațiile pentru crearea paginilor WEB dinamice este ca rezultatul să se
bazeze pe datele introduse de ușer. De exemplu într -un URL de forma
http://localhost/path?ușer=Mihai&student=yes&bursier=no , partea după semnul întrebării este
cunoscută ca “date formular” sau “date interogare” și este folosită pentru a duce informația dintr –
o pagină WEB la un program de pe server. Datele formularului pot fi atașate la sfârșitul URL –
ului după semnul întrebării pentru cereri GET, sau pot fi trimise la server într -o linie separată,
pentru cererile POST.
Citirea datelor formularului din servlet -uri: se poate face simplu pr in apelarea metodei
getParameter din clasa HttpServletRequest, furnizând numele parametrului ca argument al
metodei. Metoda getParameter se folosește în același mod atât pentru date trimise prin GET, cât
și pentru cele trimise prin POST. Servletul știe ce metodă pentru cerere a fost folosită. Valoarea
returnată este de tipul Strâng corespunzătoare valorii din URL a primei apariții a numelui
parametrului. Stringul este gol dacă parametrul nu are nici o valoare și null dacă nu există un
astfel de parametru. Dacă parametrul are mai multe valori se apelează metoda
getParameterValues care returnează un vector de stringuri.
Numele parametrilor sunt “case sensitive”, deci request.getParameter("Param1") și
request.getParameter("param1") nu pot fi interschimbate.
2.2.5 Anatomia unui servlet HTTP
Pachetul javax.servlet oferă un cadru generic pentru crearea serverelor. Conține API -uri
pentru prelucrarea cererilor și deservirea clienților. Un alt pachet, javax.servlet.http conține
implementarea servleturilor utilizate î n cazul webserverelor pentru generarea paginilor HTML.

Figure 1 – Anatomia unui servlet
Un servlet HTTP pentru a putea realiza o anumită sarcină trebuie să redefinească metoda
doGet(). Metodă este apelată de către webserver ori de câte ori serverului îi este adresată o cerere

12
HTTP care conține un GET <url>. Metodă este definită în clasa HttpServlet pe lângă metodele:
doDelete(), doOptions(), doPost(), doTrace(). Aceste metode doXXX() au doi parametri, unul de
tip ServletRequest și unul de tip ServletResponse. Cele două clase conțin metode și variabile care
permit comunicarea servletului cu webserverul și pot genera excepțiile ServletException și
IOException:
public void doGet(HttpServletRequest req, HttpServletResponse res) thro ws ServletException,
IOException {…}
Clasa ServletRequest conține toate informațiile necesare servletului pentru a înțelege
cererea și a putea răspunde la aceasta. Conține informații referitoare la calculatorul căruia trebuie
să răspundă.
Clasa ServletR esponse conține metode care permit crearea și trimiterea răspunsului.
Astfel cu ajutorul metodei setContentType( Strâng) se stabilește tipul datelor care se trimit
înapoi. Dintre tipurile posibile: text/html, text/plain . O altă metodă importantă este getWr iter().
Metoda returnează o referință de tip PrintWriter, care este un flux de ieșire prin care se trimite
răspunsul. Această metodă se utilizează dacă servletul trebuie să trimită un conținut de tip text și
metoda getOutputStream() se utilizează dacă se t rimit date binare.
2.2.6 Arhitectura pachetelor javax.servlet și javax.servlet.http
Pachetul javax.servlet oferă clase și interfețe pentru scrierea servleturilor. Principala
interfață definită în acest pachet este interfața Servlet. Toate servleturile im plementează această
interfață, cel mai des prin extinderea clasei HttpServlet.
Interfața Servlet declară metode care gestionează comunicările cu toți clienții. În
momentul când un servlet acceptă conexiunea cu un client, primește și două obiecte: (Falkner &
Jones, 2004)
 un obiect ServletRequest , care este responsabil pentru comunicarea client – server
 un obiect ServletResponse , care este responsabil pentru comunicarea inversă
server – client
Interfața ServletRequest permite servletului următoarele:
 informații despre parametrii primiți de la client, protocolul utilizat de către client,
numele hostului de la care s -a acceptat cererea
 un flux de intrare ServletInputStream. Servletul utilizează acest flux de intrare
pentru citirea datelor de la clienți . C lienții utilizează metode ca PUȚ și POST ale
protocolului HTTP
Interfața ServletResponse declară metode prin care servletul poate trimite răspunsuri la

13
cererile clienților.
 permite stabilirea lungimii răspunsului precum și tipul MIME al acestuia
 un flux de ieșire ServletOutputStream și unul Writer prin care servletul va trimite
răspunsul la cerere

2.2.7 Interacțiunea cu clienții
Un servlet HTTP tratează cererile clienților cu ajutorul metodei service(). Metoda
service() este cea care apelează metod a doGet() pentru prelucrarea cererii.
Tratarea cererilor GET și POST se face cu ajutorul următoarelor metode:
 doGet – pentru tratarea cererilor GET, GET condiționat și HEAD
 doPost – pentru tratarea cererilor POST
 doPut – pentru tratarea cererilor PUT
 doDelete – pentru tratarea cererilor DELETE
Implicit aceste metode returnează eroarea BAD_REQUEST (400) afișată de către
aplicația client (programul de navigare).
2.3. Pagini Jsp
2.3.1 Introducere
Programarea CGI (Common Gateway Interface), apărută la începutul anului 1995, a
transformat Web -ul dintr -un simplu sistem de aducere de fișiere într -o platformă în care diferitele
organizații pot instala aplicații Web de mare utilitate. Înainte de introducerea CGI Web -ul era, de
fapt, folosit pentru distribuir ea de documente statice: text și imagini. Odată cu apariția acestuia,
serverele de Web au putut fi conectate pentru a procesa informația în mod dinamic.
Aproape că nu există limite pentru posibilitățile de folosire de clienți Web în diverse
aplicații. Pro iectele ce folosesc clienți de tip browser au câteva avantaje asupra modelului
tradițional client/server. Acestea includ accesul nelimitat al clienților, instalarea și menținerea
facilă a aplicațiilor (pentru a face modificări, programatorul trebuie doar s ă schimbe un program
aflat pe server și nu câteva sute de aplicații client instalate). Ca urmare, industria de software se
îndreaptă rapid către construirea de aplicații multi -tier folosind clienți de tip browser.
Soluția incipientă reprezentată de CGI av ea serioase probleme de scalabilitate: fiecare
cerere CGI lansa un nou proces pe server, iar dacă mai mulți utilizatori făceau acest lucru
simultan, mare parte din resursele serverului Web erau astfel epuizate. Efectul imediat:
încetinirea aplicației cu ef ecte deosebit de neplăcute pentru utilizator.

14
Producătorii de servere Web au încercat să simplifice dezvoltarea de aplicații Web prin
furnizarea de "plug -in"-uri și API -uri pentru servere. Aceste soluții sunt specifice fiecărui server
și nu rezolvă proble ma în cazul unor platforme diferite. De exemplu, tehnologia Active Server
Pages (ASP) facilitează crearea de pagini de Web dinamice, însă funcționează doar cu servere
Microsoft: Internet Information Server său Personal Web Server. Conform statisticilor rec ente
22% din serverele Web sunt bazate pe NT – ceea ce înseamnă că restul de 78% are nevoie de
altceva. (Falkner & Jones, 2004)
Alte soluții există, dar nu sunt ușor de folosit de către proiectantul obișnuit de pagini de
Web. Tehnologia Java Servlets (spe cificată de API -ul Servlet de la Sun), de exemplu, permite
folosirea limbajului Java ca mediu de dezvoltare pentru crearea dinamică a păgânilor Web,
pentru execuția unor calcule în funcție de specificul aplicației sau pentru comunicarea cu surse de
date de nivel third -tier. Aceste trei activități diferă foarte mult una de cealaltă și necesită diverse
aptitudini de programare. Un servlet Java este un program ce rulează pe server (spre deosebire de
applet -uri ce rulează în browser); el preia cereri HTTP de la browser -ul Web și generează
dinamic un răspuns HTML (sau XML). Întreaga pagină Web trebuie astfel să fie conținută în
servlet -ul Java. Dacă un Web designer sau un Web master dorește să schimbe look -ul paginii
respective, ar trebui să editeze și să recompi leze servlet -ul chiar dacă modul de funcționare ce stă
în spatele acestuia rămâne același.
Proiectanții Web sunt preocupați în special de aspectele estetice ale paginii (amplasarea și
aspectul imaginilor, al fundalului și al frame -urilor) și mai puțin de sursă și de manipularea
datelor dinamice necesare pentru a aduce pagina în forma cerută de client. Uneori sunt necesare
informații despre cererea browser -ului client (cum ar fi tipul acestuia) pentru a se returna un
conținut adecvat care să beneficieze de toate avantajele acestuia. Ar fi deci foarte util să se
permită proiectanților Web accesul la aceste informații fără a trebui să învețe să scrie servlet -uri,
să le compileze și să le instaleze pe serverele de Web respective.
Pentru a oferi proiectanților acces la API -ul Servlet fără a trece prin cele trei faze
menționate anterior cât și pentru a veni cu o soluție pentru problemele deja existente, Sun a
definit specificația JavaServer Pages ce permite ca Java să devină limbaj de scripting pe partea
de serve r și mai mult decât atât.
2.3.2 Ce este JSP?
Java Server Pages (JSP) este una dintre cele mai puternice tehnologii Web și este ușor de
utilizat. JSP combină HTML și XML cu servleturile și tehnologia JavaBeans pentru a crea un
mediu destul de productiv p entru dezvoltarea de situri Web independente de platforma și de o
înaltă performanță.

15
Tehnologia JSP facilitează crearea conținutului dinamic pe partea de server a păgânilor
Web. Este asemănătoare cu ASP (Active Server Pages) de pe platforma Microsoft Wind ows și cu
PHP (PHP:Hypertext Processor), care este independent de platformă. JSP este o soluție Java
pentru programarea pe partea de server, fiind o alternativă la CGI -urile clasice (Common
Gateway Interface). JSP integrează numeroase tehnologii Java cum a r fi servleturile, JavaBeans
și JDBC. (Falkner & Jones, 2004)
JSP extinde limbajul HTML oferind posibilitatea inserării de secvențe de cod Java prin
intermediul unor taguri speciale. Programatorul are posibilitatea de a crea noi taguri și
componente Java B eans cu semnificațiile indicate de acesta. Astfel, se pot crea noi facilități
pentru cei care se ocupă de partea de web design.
În același timp, JSP este o extensie a servleturilor. În loc să scriem cod Java care să
genereze pagini Web,vom crea pagini Web care să conțină elemente dinamice.Atunci când se
primește o cerere de pagina JSP, se creează un servlet din respectiva pagină și acesta se execută,
iar rezultatul este trimis ca răspuns la cererea primită. Un avantaj important al JSP -urilor față de
servlet uri este faptul că se separă conținutul HTML static de cel dinamic. În cazul servleturilor,
orice modificare minoră referitoare la designul paginii Web implică recompilarea respectivului
servlet.
La JSP -uri, partea de generare a conținutului dinamic este p ăstrată separat de cea statică
prin utilizarea componentelor JavaBeans externe. Orice modificare a parții statice va fi vizibilă
celor ce accesează respectivul JSP, întrucât la primirea cererii se recompilează automat și foarte
repede pagina JSP apoi se ex ecută și rezultatul este trimis.
O dată scrisă, o pagină JSP poate fi stocată pe orice server Web (care are suport pentru
JSP), oricare ar fi platforma pe care se află acesta, fără a suferi modificări.
Nu există limitări referitoare la tipul conținutului g enerat de părțile dinamice ale JSP –
urilor. Acesta poate fi text obișnuit, HTML/DHTML, XML, WML, VRML etc.
JSP-urile sunt mai ușor de creat și pot avea funcționalitatea aproape a oricărui servlet.
Servleturile sunt utilizate pentru a extinde funcționalitate a serverului Web (servicii de
autentificare, validarea bazelor de date etc.) și pentru comunicarea cu appleturi sau alte aplicații
Web.
JavaServer Pages este tehnologia platformei Java pentru construirea de aplicații ce
cuprind pagini de Web cu conținut di namic precum HTML, DHTML, XHTML și XML. Sun a
încercat să depășească limitările soluțiilor actuale pentru generarea de pagini cu conținut dinamic
prin dezvoltarea unei tehnologii care:
* să funcționeze pe orice server Web sau de aplicații

16
* să separe logica ce stă în spatele aplicației de aspectul paginii
* să permită dezvoltare și testare rapidă
* să simplifice procesul de dezvoltare de aplicații interactive Web
Tehnologia JSP a fost creată să satisfacă aceste cerințe, fiind rezultatul unei cooperări la
nivel ul industriei software dintre producătorii de servere Web, servere de aplicații, sisteme
tranzacționale și unelte de dezvoltare. Astfel, procesul dezvoltării de pagini de Web dinamice
este accelerat de către JS P din următoarele considerente: (Falkner & Jon es, 2004)
 Separarea generării conținutului de prezentare
Prin tehnologia JavaServer Pages, proiectanții de pagini folosesc tag -uri obișnuite HTML
sau XML pentru formatarea rezultatului și tag -uri JSP sau scriplet -uri pentru generarea
conținutului dinamic al paginii. Logica ce stă în spatele generării conținutului este cuprinsă în
tag-uri și componente JavaBean, legătura dintre acestea făcându -se în scriplet -uri și totul fiind
executat pe server. Astfel, proiectanții de pagini sau Web master -ii pot edita și lucra cu pagini
JSP fără a afecta generarea conținutului dinamic.
Pe partea de server, un engine (motor) JSP interpretează scriplet -urile și tag -urile JSP,
generează conținutul cerut (accesând componente JavaBean, baze de date folosind JDBC sau
prin incl uderea de fișiere) și trimite rezultatele înapoi sub forma unei pagini HTML (sau XML)
către browser.
 Reutilizarea componentelor și a tag -urilor
Tehnologia JSP permite reutilizarea componentelor precum JavaBeans, Enterprise
JavaBeans sau a tag -urilor atât independent, cât și în cadrul unor unelte interactive de dezvoltare
a componentelor și paginilor de Web. Creatorii de pagini Web nu sunt întotdeauna programatori
familiarizați cu limbaje de scripting. JSP încapsulează funcționalitățile necesare pentru cre area de
conținut dinamic în tag -uri de tip XML specifice JSP. Tag -urile JSP standard pot accesa și
instanția componente JavaBean, pot seta sau obține atribute ale bean -urilor, pot face download la
applet -uri și pot executa funcții ce ar fi dificil de imple mentat. Tehnologia JSP este extensibilă
prin dezvoltarea de biblioteci de tag -uri definite de utilizator. Cu timpul vor fi create biblioteci
proprii de tag -uri pentru funcțiile folosite cel mai frecvent.
 "Write once, run anywhere"
Tehnologia JSP este com plet independentă de platformă atât în ceea ce privește paginile
de Web dinamice, cât și serverele de Web și componentele acestora. Aceasta este explicabil
deoarece limbajul de scripting pentru paginile JSP se bazează pe Java și în special pe modul de
mani pulare a obiectelor în acest limbaj.

17
2.3.3 Structura unei pagini JSP
O pagină JSP (*.jsp) este o pagină HTML sau XML ce cuprinde elemente adiționale (tag –
uri, declarații, scriplet -uri) pe care motorul JSP le procesează și le elimină returnând o pagină
standard HTML/XML. Ea corespunde unui document ce descrie procesarea unei cereri pentru a
crea un răspuns. (Falkner & Jones, 2004)
O pagină JSP cuprinde în structura sa:
* cod HTML/XML standard – cod ce rămâne neinterpretat de motorul JSP
* directive JSP – directive ce furnizează informații globale independente conceptual de
o anumită cerere adresată paginii JSP
* tag-uri JSP – spre deosebire de directive, tag -urile depind de fiecare cerere în parte
adresată paginii JSP
* elemente de scripting – acestea putând fi: declarații, scriplet -uri și expresii
Directive, tag -uri, obiecte și domenii de vizibilitate
Paginile JSP folosesc directive JSP pentru a transmite instrucțiuni motorului JSP. În
specificația 1.0 aceste directive sunt:
 <%@ include …%> – folosită pentru a însera în pagină un document extern ce poate
fi și un alt document JSP
 <%@ page …%> – folosită pentru a transmite informații referitoare la pagină precum
limbajul de scripting, buffer -ul, informații despre thread -uri, "pachete importate",
modul de tratare al excepțiilor etc
 <%@ taglib …%> – indică o bibliotecă de tag -uri pe care pagina respectivă le poate
invoca. Nu este disponibilă în implementările actuale
JSP include o serie de tag -uri standard. Sintaxa lor este cea a tag -urilor XML (< tag attr1
= "valoare atribut" …> corp </tag> sau < tag attr1="valoare atribut" …/>). Acestea sunt:
 <jsp:forward> – înaintează cererea către un alt fișier HTML, fișier JSP sau servlet
 <jsp:include> – include în etapa de procesare a cererii fișier ul specificat în tag
 <jsp:plugin> – face download către browser -ul clientului la un plugin Java pentru
executarea unui applet sau a unui Bean. Nu este disponibil în implementările actuale
 <jsp:useBean> – declară folosirea unei instanțe, a unei compon ente JavaBean. Dacă
aceasta nu există atunci componenta JavaBean instanțiază și înregistrează tag -ul
 <jsp:setProperty> – setează valoarea unei anumite proprietăți a unui Bean
 <jsp:getProperty> – obține valoarea unei instanțe a unui Bean, o converteșt e la
Strâng și o depune în obiectul implicit de ieșire ouț

18
O pagină JSP poate crea și/sau accesa, la procesarea unei cereri, anumite obiecte Java.
Obiectele astfel create pot deveni vizibile elementelor de scripting prin variabile în limbajul de
scriptin g. Acestea vor conține, în timpul etapei de procesare a cererilor, referințe către obiectul
respectiv. Obiectele create au un atribut numit scope ce definește domeniul de vizibilitate al
acestora: când există o referință la acest obiect și când aceasta va fi înlăturată. Valorile pe care le
poate avea atributul scope sunt:
 page – accesibil doar în cadrul paginii în care a fost creat obiectul
 request – accesibil din paginile ce procesează aceeași cerere în care a fost creat
obiectul
 session – accesibil din paginile ce se sunt în aceeași sesiune în care a fost creat
obiectul
 application – accesibil din paginile de procesează aceeași aplicație în care a fost creat
obiectul. Toate referințele la acesta sunt eliberate când mediul runtime solicită
ServletContex t-ul
Numele atașat unui obiect este unic pe tot timpul execuției, toate domeniile de vizibilitate
comportându -se ca unul singur în cadrul unei secvențe cerere/ răspuns. Lipsa transmiterii
variabilelor de stare prin HTTP este suplinită în mod automat de că tre motorul JSP prin cele două
modalități cunoscute: cookie -uri, respectiv rescrierea URL -urilor. Cât timp sunt făcute cereri
procesate de către motorul JSP, rescrierea URL -urilor este făcută în mod automat.
Orice pagină JSP conține o serie de obiecte cre ate implicit :
 request – cererea ce a solicitat pagina respectivă
 response – răspunsul la cerere
 pageContext – contextul paginii curente
 session – obiect de tip sesiune pentru clientul solicitat (valabil doar pentru HTTP)
 application – contextul servl et-ului generat (getServletConfig().get Context())
 config – obiect de tip ServletConfig pentru această pagină
 page – instanță a clasei create pentru această pagină (pentru Java: this)
 exception – excepția declanșată anterior putând fi folosită doar în pa gina de eroare
invocată
 config – obiect de tip JspWriter ce scrie în stream -ul de ieșire
Un client Web poate face o cerere direct către un servlet Java, care generează conținutul
dinamic, stochează rezultatul într -un Bean și invocă pagina JSP. Pagina JSP accesează conținutul
dinamic din Bean și trimite răspunsul (HTML) browser -ului.

19
CAPITOLUL 3 – DEZVOLTAREA APLICAȚIILOR WEB ÎN
SPRING

3.1 Prezentare Generală A Framework -Ului Spring

Spring este cel mai popular framework al aplicațiilor Java. Milioane d e dezvoltatori din
întreaga lume folosesc Spring Framework pentru a crea coduri de înaltă performanță, ușor de
testat și reutilizabile.Spring este o platformă Java open source. A fost inițial scris de Rod Johnson
și a fost lansat pentru prima dată sub lic ența Apache 2.0, în iunie 2003. Spring este mai simplu și
atunci când vine vorba de mărime și transparența. Versiunea de bază a Spring framework este de
aproximativ 2 MB. (Mudunuri, 2013)
Funcționalitățile principale ale frameworkului Spring pot fi folosite în dezvoltarea oricărei
aplicații Java, dar există și extensii pentru construirea de aplicații web pe platforma Java EE.
Obiectivele principale ale acestui framework sunt de a face dezvoltarea J2EE mai ușor de utilizat
și de a promova bune practici de pro gramare prin modelul de programare.
Beneficiile utilizării frameworkului Spring:
 Spring permite programatorilor să dezvolte aplicații utilizând modelul POJO. Beneficiul
utilizării numai a acestui model constă în faptul că nu este nevoie de un container EJB ,
cum ar fi un server de aplicații, putând utiliza doar un container robust de servlet, cum ar
fi Tomcat.
 Spring este organizat într -o manieră modulară, având o arhitectură stratificată. Chiar dacă
numărul de pachete și clase este substanțial, programatoru l trebuie să se preocupe doar
ceea ce are nevoie și să ignore restul.
 Spring vine cu unele dintre tehnologiile existente, cum ar fi cadrul ORM, cadrul de
logare, J2EE și JDK Timers etc. De aceea nu este nevoie să se integreze în mod explicit
aceste tehnolo gii.
 Spring WEB framework are un MVC (model view controller) bine conceput, care oferă o
alternativă excelentă la frameworkul web.
 Spring a adoptat cele mai bune practici care au fost folosite de -a lungul anilor în mai
multe aplicații și au fost formalizat e ca modele de design (engl. design patterns).
 Spring poate fi folosit pentru dezvoltarea mai multor tipuri diferite de aplicații, cum ar fi
aplicații independente, aplicații GUI independente, aplicații Web și applet -uri.

20
 Spring folosește Dependency Inject ion. Ce este exact injecția de dependențe? Să privim
aceste două cuvinte separat. Aici, partea de dependență se traduce într -o asociere între
două clase. De exemplu, clasa A este dependentă de clasa B. Cel de -al doilea cuvânt,
injectarea înseamnă că, clasa B va fi injectată în clasa A de către IoC. Atunci când se
scrie o aplicație Java complexă, clasele aplicației ar trebui să fie cât mai independente
posibil de alte clase Java pentru a crește posibilitatea reutilizării acestor clase și de a le
testa indepe ndent de alte clase. Dependency Injection ajută la lipirea acestor clase
împreună și, în același timp, menținerea lor independentă.
3.2 Arhi tectura Spring

Spring este modular, permițând alegerea modulelor care sunt necesare în funcție de
fiecare caz în pa rte. Următoarea secțiune oferă detalii despre toate modulele disponibile în Spring
Framework. Acesta oferă aproximativ 20 de module care pot fi utilizate în funcție de cerințele
aplicației.

Figure 2 -Arthitectura Spring

Core Con tainer este format din modulele Core, Beans, Context și Expression Language,
ale căror detalii sunt după cum urmează:
 Modulul Core furnizează părțile fundamentale ale frameworkului, inclusiv caracteristicile
IoC și Dependency Injection.
 Modulul Bean oferă BeanFactory, care este o implementare sofisticată a factory pattern.

21
 Modulul Context se bazează pe baza solidă furnizată de modulele Core și Beans și este un
mediu de acces la orice obiecte definite și configurate. Interfața ApplicationContext este
punctul focal al modulului Context.
 Modulul SpEL oferă un limbaj puternic pentru interogarea și manipularea unui obiecte în
timpul rulării.
Data Access/Integration cuprinde modulele JDBC, ORM, OXM, JMS și Transaction,
ale căror detalii sunt următoarele:
 Modulul J DBC oferă un layer de abstractizare JDBC care elimină necesitatea codării
obositoare ce are legătură cu JDBC.
 Modulul ORM este legat de accesul la baza de date. Oferă niveluri de integrare pentru
mapări obiectual -relaționale populare, incluzând JDO, Hibern ate și IBatis.
 Modulul OXM oferă un layer de abstractizare care conține Object / XML implementări
de mapare pentru JAXB, Castor, XMLBeans, JiBX și XStream.
 Modulul JMS (Java Messaging Service) conține instrumente pentru producerea și
consumarea mesajelor.
 Modulul Transaction cuprinde gestionarea tranzacțiilor programate și declarative pentru
clasele care implementează interfețe speciale și pentru toate POJO -urile.
Layerul Web este alcătuit din modulele Web, Web -MVC, Web -Socket și Web -Portlet,
caracteristic ile acestora fiind următoarele:
 Modulul Web oferă instrumente de bază web -oriented, cum ar fi funcționalitatea de
încărcare a fișierelor multiple și inițializarea containerului IoC utilizând servlet listeners
și un context de aplicație web -oriented.
 Modulu l Web -MVC conține implementarea Spring -ului Model -View -Controller (MVC)
pentru aplicațiile web.
 Modulul Web -Socket oferă suport pentru WebSocket, comunicare în ambele sensuri,
între client și server în cadrul aplicațiilor web.
 Modulul Web -Portlet prevede c a implementarea MVC să fie utilizată într -un mediu
portlet și reflecta funcționalitatea modulului Web -Servlet.
Există câteva alte module importante, cum ar fi modulele AOP, Aspects,
Instrumentation, Web și Test, ale căror caracteristici de bază sunt următo arele:
 Spring AOP – Una dintre componentele cheie ale spring este cadrul AOP. Acesta este
folosit pentru a oferi servicii enterprise declarative, mai ales ca un înlocuitor pentru
serviciile EJB declarative. Cel mai important asemenea serviciu este manageme ntul
tranzacțional declarativ. Altă utilitate a AOP este de a permite utilizatorilor să

22
implementeze aspecte personalizate, completând utilitatea OOP -ului cu AOP.
 Modulul Aspects oferă integrarea cu AspectJ, care este din nou un framework AOP
puternic și m atur.
 Modulul Instrumentation oferă suport în instrumentarea claselor.
 Modulul Messaging oferă suport pentru STOMP ca subprotocol WebSocket pentru
utilizare în aplicații. De asemenea, acceptă un model de programare prin folosirea
adnotărilor pentru rutarea și procesarea mesajelor STOMP de la clienții WebSocket.
 Modulul Test acceptă testarea componentelor Spring frameworkuri ca JUnit sau TestNG.
3.3 Inversiunea De Control Prin Spring Framework (Ioc) Și Injectarea
Dependențelor
3.3.1 Dependențele între obiect e
La baza ei, o aplicație Java este formată din obiecte care colaborează între ele pentru
rezolvarea unei probleme – obiectele având dependențe între ele, platforma Java, însă, nu
dispune de mijloacele necesare pentru organizare obiectelor. Sarcina organiz ării obiectelor revine
dezoltatorilor și arhitecților care au la dispoziție design pattern -urile pentru a organiza clasele și
obiectele. Totuși, programatorul va fi cel care va implementa această organizare. (Tudose, 2016)
Inversiunea de control prin Sprin g Framework (Inversion of Control – IoC) facilitează
această problemă – organizarea obiectelor – oferind mijloacele necesare pentru a permite
componentelor disparate să fie asamblate într -o aplicație funcțională.
Pentru a explica mai bine cele spune anterio r, vom prezenta un exemplu care ilustează
cum pot fi gestionate dependențele între obiecte. Vom porni de la o situație simplă, în care avem
două clase în care una va ține o referință către un obiect care va aparține celei de -a două clase.
Astfel, vom pune în evidență modalitățile de a menține această dependență prin abordarea
tradițională care menține legătura dintre clase în interiorul codului și abordarea Spring asupra
dependențelor între obiecte.
Abordarea tradițională – menține legătura dintre clase î n interiorul codului

public class Person {
private Strâng name;

23
private Company company;
public Person() {
name = "John Smith";
company = new Company();
company.setName("ABC Softwar e");
}
}
public class Company {
private Strâng name;
public void setName(Strâng name) {
this.name = name;
}
}
Codul, care se află mai sus, creează un obiect aparținând clasei Company pe care îl
utilizează într -un singur loc – o abordare ineficientă. Astfel, putem rezuma la modul general, prin
schema de mai jos, cum sunt tratate dependențele între obiecte în abordarea tradițională.

Problemele care pot fi constatate în această abordare „tradițional ă” sunt:
 Clasa A depinde direct de clasa B. Ambele clase sunt strâns legate în cazul eventualelor
schimbări,acestea se vor propaga în tot codul.
 Ciclul de viață al obiectului de tip B depinde de obiectul de tip A și va fi imposibilă utilizarea
obiectului de tip B în alte locuri.
 Nu se va putea înlocuim clasa B cu o altă implementare, lucru care se poate întâmpla în mod
frecvent în dinamica unui proiect.
 Clasa A nu poate fi testată separat de clasa B.

3.3.2 Abordarea Spring asupra dependențelor între obiec te
Injectarea dependenței (Dependency Injection – DI) este cunoscută și drept inversiune de
control (Inversion of Control – IoC). Este un proces prin care obiectele își definesc dependențele
– mai exact, alte obiecte către care păstrează referințe – cu aju torul argumentelor de constructori,

24
argumentelor de metode “factory” sau proprietăților care sunt setate de către obiect după ce
acesta a fost construit.Injectarea acestor dependențe este realizată de containerul care se ocupă de
gestiunea bean -urilor.
Acest proces este inversul celui tradițional, astfel și denumirea de inversiune de control
(Inversion of Control – IoC), bean -ul fiind cel care își controlează instanțierea și localizarea
dependențelor.

public class Person {
private Strâng name;
private Company company;
}
public class Company {
private Strâng name;
}
Dependențele sunt separate, într -un fișier de configurare XML.
<bean id=”smith” class=”Person”>
<property name=”name” value=”John Smith”/>
<propert y name=”company” ref=”luxoftCompany”/>
</bean>
<bean id=”luxoftCompany” class=”Company”>
<property name=”name” value=”Luxoft”/>
</bean>

Avantajele care sunt pot fi constatate acestui tip de abordare:
 Atunci când este solicitat un obiect, contai nerul este cel care decide ce anume trebuie returnat.
 Dependențele sunt înregistrate la nivelul containerului pentru oricare din tipuri.
 Este ușor să se realizeze schimbări asupra dependențelor obiectelor.
 Clasele Person și Company nu sunt dependente între ele așa cum era cazul în primul exempul.
 Fișierul de configurare XML documentează configurarea sistemului și dependențele între
obiecte.
 Containerul controlează ciclul de viață al obie ctelor create

25
Inversiunea de control (IoC) este considerată baza framew ork-ului Spring și mai este
cunoscută și sub denumirea de “Principiul Hollywood”: “Nu ne căutați dumneavoastră, vă vom
căuta noi”.Principiul a plecat de la ideea de bază de a elimina dependența componentelor
aplicației de anumite implementări și de a dele ga către container drepturile de a controla
instanțierea claselor.Astfel, containerul este cel care știe când „să caute”, Este recomandat să se
insereze în interiorul containerului acele obiecte a căror implementare se poate schimba, astfel
avantajele fii nd următoarele:
 managementul dependințelor și modificarea acestora se face fără a fi nevoie de recompilarea
codului. De aici rezulta un timp de dezvoltare și un număr de operații mai mic.
 reutilizarea claselor este facilitată.
 menținerea codului este mai s implă, nu este nevoie de inițializarea unor obiecte auxiliare.
3.3.3 Inversion of Control vs Dependency Injection
Scopul principal al Inversion of Control și Dependency Injection este de a elimina
dependențele unei aplicații. Având în vedere că ambele au a celași scop, exista o confuzie între
IoC și DI. IOC (Inversion of control) este un termen general parental, în timp ce DI (Dependency
Injection) este un subset al IOC.

Figure 3 – Inversiunea controlului – schema

Inversiunea cont rolului este termen generic, independent de limbaj, nu ține, de fapt, de
crearea obiectelor, ci de descrierea în care obiectul este creat. Acesta este un concept în care
fluxul aplicației este inversat prin acordarea controlului containerului pentru a obți ne o instanță a
obiectului. Asta înseamnă că în loc să creați un obiect folosind noul operator, permiteți acestuia

26
să facă acest lucru pentru dvs.
Injectarea dependenței este termenul concret, în care oferim dependențe ale obiectului în
timpul de execuție prin folosirea diferitelor tehnici de injecție( Setter Injection, Constructor
Injection sau Interface Injection). Codul este mai curăț cu principiul DI și decuplarea este mai
eficientă atunci când obiectele sunt furnizate cu dependențele lor. Obiectul nu î și caută
dependențele și nu cunoaște locația sau clasa dependențelor, mai degr abă totul este făcut de
Spring.
3.4 Spring Mvc
Cadrul MVC oferă arhitectura Model -View -Controller (MVC) și componente gata care pot fi
folosite pentru a dezvolta aplicații web fl exibile. Modelul MVC are ca rezultat separarea
diferitelor aspecte ale aplicației (logica de intrare, business logic -ul și logica UI), oferind în
același timp o independentă între aceste elemente.
Denumirea de MVC vine de la Model -View -Controller:
 Model – încorporează datele aplicației și, în general, acestea vor consta în POJO.
 View – este responsabil pentru redarea datelor modelului și, în general, generează output
HTML pe care browserul clientului îl poate interpreta.
 Controller – este responsabil pentru pr ocesarea cererilor de utilizator și construirea unui
model adecvat pe care îl transmite view pentru redare.
Spring MVC este proiectat în jurul unui DispatcherServlet care gestionează toate cererile și
răspunsurile HTTP. Cererea procesării fluxului de lucru a Spring Web MVC DispatcherServlet
este ilustrata în următoarea diagramă:

Figure 4 – Schema Spring MVC
Ceea ce urmează este secvența evenimentelor care corespund unei cereri HTTP primite către

27
DispatcherServlet –
 După primirea unei solicitări HTTP, DispatcherServlet consultă HandlerMapping pentru
a apela controlerul corespunzător.
 Controlorul preia cererea și apelează metodele service corespunzătoare pe baza metodei
GET sau POST utilizată. Metoda service va stabili datele modelu lui bazate pe business
logic -ul definit și va returna numele view -ului către DispatcherServlet.
 DispatcherServlet va primi ajutor de la ViewResolver pentru a prelua view -ul definit
pentru cerere.
 Odată ce view -ul este finalizat, DispatcherServlet -ul transm ite datele model la view care
este redat, în final, în browser.
 Toate componentele menționate mai sus, adică HandlerMapping, Controller și
ViewResolver, fac parte din WebApplicationContext w, care este o extensie a
plainApplicationContext cu câteva caracte ristici suplimentare necesare pentru aplicațiile
web.

28
CAPITOLUL 4 -TEHNICI DE MAPARE OBIECTUAL –
RELATIONALE (ORM) CU JPA ȘI HIBERNATE
4.1 Introducere
Platforma Spring sprijină integrarea cu Hibernate, Java Persistence API (JPA) pentru
managementul resurselor, implementarea de obiecte de acces la datele din baza de date (DAO) și
strategii de tranzacționare. De exemplu, pentru Hibernate există suport de primă clasă, cu mai
multe caracteristici convenabile pentru IoC care abordează multe prob leme tipice de integrare în
Hibernate. Se pot configura toate funcțiile acceptate pentru instrumentele de mapare O/R (object
relațional) prin injectarea de dependente (Dependency Injection). (Winterfeldt, 2008)
Printre avantajele folosirii Spring ORM se p ot enumera următoarele:
 se scrie mai puțin cod: Cu ajutorul Spring, nu este necesar să se scrie cod suplimentar
înainte și după logica actuală a bazei de date, cum ar fi obținerea conexiunii, începerea
tranzacției, comiterea tranzacției, închiderea conexi unii etc.
 este ușor de testat: Abordarea IoC a Spring -ului facilitează testarea aplicației.
 o mai bună gestionare a excepțiilor: Spring oferă propriul API pentru tratarea excepțiilor
cu cadrul ORM.
 gestionarea tranzacțiilor integrate: Prin intermediul Spri ng, putem împacheta codul nostru
de mapare într -un stil declarativ fie prin intermediul adnotării @Transactional, fie prin
configurarea explicită a aspectelor AOP de tranzacție într -un fișier de configurare XML.
Java Persistence API (Java Persistence API) este o specificație Java pentru accesarea,
persistența și gestionarea datelor între obiectele / clasele Java și o bază de date relațională. JPA
este acum considerată abordarea standard a industriei pentru tehnica de mapare obiectual –
relationala (ORM) în i ndustria Java.
JPA este doar o specificație, nu un produs; Nu poate face persistență sau altceva în sine. JPA
este doar un set de interfețe și necesită o implementare. Există implementări JPA open -source și
comerciale pentru a alege și orice server de apli cații Java EE 5 ar trebui să ofere suport pentru
utilizarea acestuia. De asemenea, JPA impune folosierea unei baze de date în care se va face
persistarea datelor. Specificația JPA este implementata de mulți furnizori, cum ar fi: Hibernate,
Toplink, OpenJP A etc.
În continuare vom prezenta modul în care framewok -ul Spring oferă support pentru JPA
folosind implementtare Hibernate, dar și exemple concrete din aplicația Tennis Stars.

29
4.1.1 Configurarea bean -ului SessionFactory în containerul Spring
Spring pe rmite definirea unor resurse ca JDBC DataSource sau Hibernate SessionFactory
ca bean -uri în containerul Spring. Obiectele de aplicație care au nevoie de acces la resurse
primesc doar referințe la astfel de instanțe predefinite prin referințe de bean -uri (d efiniția DAO
din următoarea secțiune ilustrează acest lucru). Următorul fragment de cod reprezintă
configurarea în aplicația Tennis Stars a resurselor menționate mai sus, sursa de date JDBC și o
sesiune de tip Hibernate SessionFactory în partea de sus a ac esteia:

4.1.2 Configurarea entităților JPA
Un tabel dintr -o bază de date relațională este reprezentată în program printr -o entitate
JPA, o clasă Java marcată cu adnotarea @Entity . O instanță a unei entități JPA corespunde unei
linii din tabela asociată. Corespondența dintre o entitate JPA și o tabelă din baza de date se
realizează folosind adnotări în clasa Java care reprezintă entitatea JPA. Astfel, de exemplu,
@Table specifică numele tabelei cu care entitatea este asociată, @Column desemnează numele
coloanei din tabelă cu care este asociat câmpul marcat al entității JPA, @Id marchează un câmp
al entității care corespunde unei chei primare în tabela asociată.

30

Relațiile dintre tabele sunt reprezentate în entitățile JPA tot prin adnotări:
– One-to-one, în care o instanță a unei entități este legată (relaționată) cu o singură instanță
a altei entități.
– One-to-many , în care o instanță a unei entități poate fi legată (relaționată) la mai multe
instanțe ale celeilalte entități. Exemplul clasic este cel al unei comenzi (order) care poate
avea mai multe linii.
– Many -to-one, este relația inversă față de one -to-many, când mai multe instanțe ale unei
entități pot fi legate (relaționate) la o instanță a celeilalte entități.
– Many -to-many , când instanțele unei entități pot fi legate la mai multe instanțe ale
celeilalte entități. De exemplu, un curs are mai mulți studenți și fiecare student urmează
mai multe cursuri.
Următoarele clase importante sunt clasele Repository care utilizează managerul de entități
(bean -ul entit yManager) pentru a efectua operațiuni CRUD utilizând entități de hibernare și
pentru a specifica metode care susțin tranzacțiile prin adnotarea @Transactional . În cazul
nostru, am aplicat adnotarea @Transactional la nivel de metodă în clasele de tip Servic e ce pot
apela mai multe metode din Repository , adnotarea putând fi folosită și la nivel de clasa ceea ce
ar determina toate metodele publice să fie tranzacționale.

31

32
CAPITOTUL 5 – DESCRIEREA APLICAȚIEI ȘI A
TEHNOLOGIILOR FOLOSITE ÎN CONTEXTUL DA T

Conținutul informațional din întreaga lume, în zilele noastre, este convertit la o formă
digitală, făcând astfel informațiile disponibile oricui, oriunde și oricând. Prin intermediul
sistemelor informatice, multe dintre activitățile pe care omul le într eprinde pot fi ușurate și chiar
îmbunătățite. Aplicația Tennis Stars a fost concepută pentru a fi folosită de către jucătorii amatori
de tenis, dar și de către organizatorii de turnee, în vederea creării unui mediu competițional și
aducerii laolaltă a tutu ror pasionaților sportului alb. Aplicația își propune să mențină o bază de
date cu clasamentul, datele personale și competițiile la care au participat jucătorii. De asemenea,
organizatorii își pot actualiza turneele sau/ și datele jucătorilor la cerere.
5.1 Tehnologiile Și Uneltele Folosite
Scopul acestui subcapitol este de a face referire la toate instrumentele de dezvoltare care
au contribuit la realizarea obiectivelor acestui proiect. Deoarece nivelul de complexitate al
acestui proiect a fost ridicat, pr ocesul de dezvoltare al proiectului a implicat utilizarea mai multor
tehnologii.
Această aplicație a fost scrisă în limbajul de programare Java folosind platforma de
dezvoltare software Intelij IDE.
Tehnologii utilizate în procesul de proiectare și dezvolt are sunt:
– Java Development Kit , JDK 8
– Spring framework 4.2.2.RELEASE
– InteliJ IDE 13.1.7;
– Maven 3.3.9 pentru rezolvarea și descărcarea dependentelor
– SVN folosit pentru a face modificările într -un mod incremental folosind un loc comun în
care se află proiec tul numit repository. Repository -ul a fost făcut pe platforma
www.assembla.com prin crearea unui cont gratuit.
– https://creately.com/ o platformă online prin intermediul căreia s -au construit diagramele
UML.
– https://logomakr.com/ o platformă online prin intermediul căreia s -au construit logo -ul
aplicației și alte pictograme.
– MySQL server 5.7
– MySQL Workbench 6.3 pentru crearea și modelarea bazei de date
– Tomcat 7

33
– Bootstrap version 3.3. 6
5.2 Cazuri De Utilizare ( Use Cases )

În continuare, se vor prezenta cazurilor de utilizare ale aplicației care vor oferi o descriere
generală a modului în care va fi utilizat sistemul, se va furniza o privire de ansamblu a
funcționalităților ce se doresc a fi oferite de sistem și va arăta cum interacționează sistemul cu
unul sau mai mulți actori.
În sistemul software prezentat, putem indentifică 2 actori și anume:
– TennisPlayer – jucătorul de tenis
– Admin – admnistratorul systemului software
Cazurile de uti lizare corespunzătoare funcționalității descrise sunt următoarele:

Figure 5-Cazuri de utilizare
Exmplificarea cazurilor:

34
 Atât ușerul Player cât și actorul de tip Admin se pot autentifica în aplicație prin
introducerea datelor de autentificare personale, username și parola.

Figure 6 -Cazuri de utilizare
Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au drep tul să
acceseze aceasta pagină.

 După autentificare, ușerul se va afla pe p agina HomePage.

Figure 7-Caz de utilizare: Homepage
Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au dreptul să
acceseze aceasta pagină.

35
 Următorul tab este Players. Acesta afișează lista jucătorilor. Lis ta este ordonată după
Rank, cel mai bine -clasat jucător fiind afișat primul în tabel după numărul de puncte.Pe
acceasi pagina, se găsesc elemente de control :

– Find player cauta în baza de date textul introdus de utilizator în căsuța de căutare
după numel e sau prenumele jucătorului. Algoritmul de căutare afișează doar
jucătorii al căror nume sau prenume începe cu textul introdus.
– Add player poate fi accesat doar de către un utilizator cu rolul admin. Acesta oferă
posibilitatea adăugării unui nou jucător. A cest use case vă fi prezentat în detaliat
într-un alt caz de prezentare.
– Numele jucătorilor afișate în table sunt asociate cu niște linkuri care vor deschide
o pagină de detalii.

Figure 8-Caz de uitilizare: Vizualizare liste juc ători
Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au dreptul să
acceseze aceasta pagină.

 Pentru a vizualiza datele unui anumit jucător, și anume detalii cum ar fi nume, adresa,

36
clasare, număr de puncte și alte detalii despre un jucător, utilizatorul/adminul trebuie să
acceseze tab -ul Players. De asemenea, se pot vizualiza realizările fiecărui jucător în
cadrul participărilor sale la competiile sportive.

Figure 9-Caz de utilizare: vizualizare detalii j ucător
Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au drep tul să
acceseze aceasta pagină.

 Următorul scenariu prezintă cazul în care un utilizator folosește funcția de căutare
jucător. Căutarea se face după numele sau prenumele jucătorilor existenți în baza de date
astfel:
o dacă numele sau prenumele unui jucător începe cu textul introdus în căsuța de
căutare, atunci acel jucător va fi afișat în lista cu rezultate;
o dacă un singur jucător este găsit conform criteriilor de căutare, atunci
utilizatorului I se va prezenta în mod automat pagina cu detalii jucătorului găsit;
o dacă niciun jucător nu este găsit în baza de date conform criteriilor de căutare,
atunci mesajul “No player found” va fi afișat.

37

Figure 10-Caz de utilizare: căutare jucător
Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au dreptul să
acceseze aceasta pagină.

 Urmatoriul scenariu prezintă cazul în care un utilizator dorește să editeze datele unui
jucător existent în aplicație. Pentru a putea ajunge pe acesta pagina, utilizatorul trebuie să
aibă rolul de ADMIN. Dupa ce se autentifica în aplicație cu userul și parola,
administratorul poate ajunge pe pagina de editare detalii jucător fie prin căutarea jucătorul
după num e sau prenume, fie prin accesarea directă a jucătorul dând click pe numele
acestuia din lista de jucători.

38

Figure 11-Caz de utilizare: E ditare jucător
Permisiuni de acces : doar utilizatorii cu rolurile ROLE_ADMIN au dreptul să ac ceseze aceasta
pagină.

 Urmatoriul scen ariu prezintă cazul în care un utilizator dorește să adauge un nou jucător în
aplicație. Pentru a putea ajunge pe acesta pagina, utilizatorul trebuie să aibă rolul de ADMIN.
După ce se autentifica în aplicație cu uș erul și parola, administratorul are acces la butonul de
“Add Player” afișat și vizibil doar pentru el pe pagina de jucători.

39

Figure 12-Caz de utilizare: A dăugare jucător
Permisiuni de acces : doar utilizatorii cu rolurile ROLE_AD MIN au dre ptul să acceseze aceasta
pagin

 Următorul caz de folosința prezintă adăugarea de noi realizări ale jucătorului. Adminul
poate adăuga după fiecare turneu la care a participat jucătorul, realizările acestuia
precum: numele turneului, data participă rii, tipul și categoria turneului.

Figure 13- Caz de utilizare:A dăugare realizări jucător

40
Permisiuni de acces : doar utilizatorii cu rolurile ROLE_ADMIN au drep tul să acceseze aceasta
pagină.

 Următorul tab este Tournaments. Ac esta afișează lista turneelor. Lista pur și simplu
afișează numele competiției, orașul în care acesta are loc, data de începere a aceștia,
categoria și tipul competiției. Pe acceasi pagina, se găsește elementul de control: Add
tournament care va fi prezent at în următorul caz de testare.

Figure 14- Caz de utilizare: V izualizare lista turnee

Permisiuni de acces : utilizatorii cu rolurile ROLE_ADMIN și ROLE_PLAYER au dreptul să
acceseze aceasta pagină.

41
 Cazul de utilizare Adăugar e turneu nou prezintă adăugarea unui nou turneu la care
jucătorul a participat. Adminul poate adăuga: numele turneului,orașul, data participării,
tipul și categoria turneului.

Figure 15- Caz de utilizare: A dăugare turneu nou

Permisiuni de acces : doar utilizatorii cu rolurile ROLE_ADMIN au dreptul să acceseze aceasta
pagină.

 Ultimul caz de folosința este cel de contactare al administratorului prin intermediul
formularului de contact. Jucătorul își adaugă numele, adresa de ema il și mesajul. Prin
apăsarea butonului Send Message, aplicația va salva sugestia sau plângerea în baza de
date iar administatorul o va putea vedea în baza de date.

42

Figure 16 – Caz de utilizare: F ormularul de contact

Permisiuni de acces : doar utilizatorii cu rolurile ROLE_PLAYER au drep tul să acceseze
aceasta pagină.
5.3 Configurarea Mediului Spring

Structura proiectului este în conformitatea cu structura Maven a unui web proiect.
Fisierile web pleacă în src/main/webapp, codul s ursă în src/main/java și resursele în
src/main/resources.
Spring Framework are nevoie de fișiere de configurare și, în acest scop, în folderul WEB –
INF sunt create folderul resouces/spring, unde se regăsesc fișierele de configurare spring.
Configurarea Spri ng Framework -ului se poate face cu ajutorul fisierilor .xml și cu
ajutorul adnotărilor plasate direct în cod. În acest proiect, s -au utilizat ambele posibilități.
Așadar, în fișierul de configurare web.xml specificam următoarele fisere de configurare
pentr u Spring Framework business -config.xml /tools -config.xml /spring -security.xml și un
listener care folosește aceste fișiere după cum urmează în figură de mai jos:

43

Definirea servletul care va face dispatching -ul, se face în felul următor:

Configurarea co nexiunii la baza de date, prin definirea bean -ului datasource, se face în fișierul de
configurare datasource -config.xml:

44

Configurarea MVC (model -view -controller) se face, după cum urmează, în fișierul de
configurare mvc -view -config.xml:

Fiecare nume de view returnat de la un handler, va fi tradus într -o resursă JSP (de
exemplu: "players" -> "/WEB -INF/jsp/players.jsp"), folosind configurarea de mai sus pentru a
activa suportul explicit JSTL.
Configurarea securității Spring, în funcție de roluri și pag ini accesate, se face în fiserul
xml de configurare spring -security.xml:

45
După cum se poate observa, pentru fiecare endpoint al aplicației TennisStars, s -a
configurat accesul pentru utilizatorii care au rolur ile ROLE_ADMIN sau ROLE_PLAYER.
5.4 Separarea Codului În Mai Multe Straturi În Funcție De Responsabilități
Având în vederea separarea codului pe mai multe straturi (layers), în funcție de
responsabilități, am indentificat și folosit următoarele straturi în aplicația TennisStars:

Figure 17- Stru ctura codului în mai multe straturi

Presentation layer include controllere și view -uri jsp – transmite datele de intrare.

Figure 18-Presentation layer

46

Services layer – mediatorul dintre controller și reposi tory. Se ocupa cu validarea datelor
primite de la controller, efectuează validarea și logica business și apelând repozitorie -urile pentru
manipularea
datelor.

Figure 19- Services layer

Repositories layer – strat pentru interacțiu nea cu modelele și efectuarea operațiilor cu
baza de date.

Figure 20- Repositories layer

Model – clase care conțin reprezentarea datelor din baza de date . În figură următoare, se
poate observa această organizare în dezvoltarea aplicației TenisStars .

47

Figure 21- Structura entităților model

Așadar, se poate observa că pentru fiecare tabel din baza de date există un model, pentru
fiecare model există un repository, pentru fiecare repository există un se rviciu și pentru fiecare
serviciu există un controller.
5.5 Arhitectura bazei de date

Figure 22- Diagrama bazei de date

48
5.6 Design Pattern -Uri Implementate De Spring Și Folosite În Aplicația
TennisStars

Deși platforma Java oferă o multitudine de funcționalități de dezvoltare a aplicațiilor,
aceasta nu dispune de mijloacele necesare de a organiza blocurile de bază într -un întreg coerent,
lăsând această sarcină arhitecților și dezvoltatorilor. Framewok -ul Spring a reușit să înglob eze o
multitudine de astfel de bune practici numite design patterns și să lase utilizatorii să -și
concentreze atenția pe logică business.
În continuare, se vor prezenta câteva din pattern -urile implementate de Spring.
5.6.1 Injectarea dependetelor (Depende ncy Injection Pattern)
Putem spune că unul dintre cele mai importante principii de dezvoltare ale aplicațiilor
Spring este Dependency Injection (DI).
La injectarea dependentelor se vorbește despre o inversare a controlului, în sensul că
gestiunea legăturil or dintre componente nu mai revine aplicației, ci frameworkului Spring.
Injectarea într -un obiect a unei referințe cãtre un alt obiect se poate face în trei moduri:
– prin constructorul clasei (“Constructor Injection”)
– printr -o metodã a clasei (“Setter I njection”)
– printr -o interfața de injectare (“Interface Injection”)
În cazul aplicației prezentate, s -a folosit injectarea de dependente prin constuctor, după cum se
poate vedea în exemplul de mai jos:

49
5.6.2 Pattern -ul Front Controller în Spring
Acest p attern este utilizat pentru a oferi un mecanism centralizat de manipulare a
cererilor, astfel încât toate cererile să fie tratate de un singur manipulator. Acest handler poate
efectua autentificarea / autorizarea / înregistrarea sau urmărirea solicitării ș i apoi transmite
cererile operatorilor corespunzători. Entitățile acestui tip de model de design sunt următoarele:
 Front Controller – Handler unic pentru toate tipurile de cereri care vin în aplicație (fie
bazate pe web / desktop).
 Dispecerul – Controller -ul frontal poate folosi un obiect expeditor care poate expedia
cererea la un anumit manipulator specific.
 View -urile – un view este obiectul pentru care se fac solicitările.
În continuare, este prezentat modul în care a fost configurat controllerul frontal în aplicația
TennisStars.
Aceasta configurare trebuie făcută în fiserul web.xml file:

<servlet>
<servlet -name>tennis -app</servlet -name>
<servlet -class>org.springframework.web.servlet.DispatcherServlet</servlet -class>
<init -param>
<param -name>contextConfigLocation</param -name>
<param -value>classpath:spring/mvc -core-config.xml</param -value>
</init -param>
<load -on-startup>1</load -on-startup>
</servlet>
<servlet -mapping>
<serv let-name>tennis -app</servlet -name>
<url-pattern>/</url -pattern>
</servlet -mapping>

5.6.3 Pattern -ul MVC – Model View Controller
Model -view -controller (MVC) este un model arhitectural software pentru implementarea
interfețelor utilizator. El îm parte o aplicație dată în trei părți interconectate, pentru a separa
reprezentările interne ale informațiilor de modalitățile în care informațiile sunt prezentate și
acceptate de la utilizator. Modelul de design MVC decuplează aceste componente majore,
permițând reutilizarea eficientă a codurilor și dezvoltarea paralelă.

50

Figure 23- Funcționarea modelului MVC

Așa cum este afișat în figură de mai sus, toate cererile de intrare sunt interceptate de
DispatcherServlet care funcționea ză ca controller frontal. DispatcherServlet -ul apoi, își căuta în
fișierul xml de configurare controllerul căruia trebuie să -i înainteze cererea. Controller -ul care
primește cererea apelează alte servicii necesare și returnează un obiect de tip ModelAndVie w.
DispatcherServlet -ul apoi își căuta în fișierul xml de configurare, view -ul pe care trebuie să îl
afișeze utilizatorului și invocă aceasta componentă.
5.6.4 Pattern -ul Factory
După cum sugerează și numele, pattern -ul Factory face uz de clasele care acți onează ca
factories pentru a crea obiecte. Acest model favorizează invocarea metodei în loc să facă apeluri
directe ale constructorilor pentru a crea obiecte.
În Spring, BeanFactory -ul este ca o clasă factory care conține o colecție de bean -uri.
BeanFactor y deține definirea mai multor bean -uri și apoi instanțiază bean -urile ori de câte ori
acestea sunt solicitate de clienți.
BeanFactory este capabil să creeze asociații între obiectele care colaborează atunci când
acestea sunt instanțiate. Acest mecanism eli mină sarcina de configurare a bean -urile în sine și a
bean -urilor client.
BeanFactory participă, de asemenea, la ciclul de viață al unui bean, făcând apeluri la
metode de inițializare și de distrugere personalizate.

51
5.6.5 Pattern -ul Singleton în Spring și Java
În ingineria software, modelul singleton este un model de design software care
restricționează instanțiarea unei clase într -un singur obiect. Acest lucru este util când este necesar
un singur obiect pentru a coordona acțiunile din cadrul sistemului.
O implementare a modelului singleton trebuie să asigure că există o singură instanță a
clasei singleton și să ofere acces global la acea instanță.
În mod similar, dacă se dorește ca Spring să returneze același bean de fiecare dată când este
nevoie, ar trebu i să declare scopul bean -ului Spring ca singleton . În acest fel, containerul Spring
IoC creează exact o singură instanță a obiectului care este stocată într -o memorie cache a unor
astfel de bean -uri singleton, iar toate cererile și referințele ulterioare p entru acel bean vor returna
obiectul din cache. În aplicația TennisStars, toate bean -urile au fost definite ca Singleton. În
Spring, scopul implicit al unui bean este întotdeauna singleton. Cu toate acestea, atunci când
aveți nevoie de o singură instanță a unui bean, puteți seta proprietatea de singleton în fișierul xml
de configurare a beanu -urilor, așa cum se arată în următorul fragment de cod:

<!– A bean definition with singleton scope –>
<bean id = "…" class = "…" scope = "singleton">
<!– collaborators and configuration for this bean go here –>
</bean>

52
Bibliografie

1. Bloch, J. (2001). Effective Java – Programming Language Guide. Boston: Addison –
Wesley.
2. C. Olaru, S. T. (2003). Java de la 0 la expert. Iasi: Polirom.
3. Eckel, B. (2006 ). Thinking in Java. Prentice Hall.
4. Falkner, J., & Jones, K. W. (2004). Servlets and JavaServer Pages. Addison -Wesley
Professional.
5. Gokul. (2013). Spring Tutorial for Java Beginners.
http://www.simplecodestuffs.com/spring -tutorial -2/.
6. Jendrock, E., Cervera -Navarro, R., Evans, I., Haase, K., & Markito, W. (2014). Java EE
7 Tutorial, The: Volume 1, 5th Edition. Addison -Wesley Professional .
7. Mudunuri, S. (2013). Spring Framework: A Step by Step Approach for Learning Spring
Framework. Phoenix: CreateSpace Indep endent Publishing Platform.
8. Oracle. (2013). The Java EE 6 Tutorial.
http://docs.oracle.com/javaee/6/tutorial/doc/bnadr.html .
9. Spring Tutorial. (n.d.). https://www.tutorialspoint.com/spring/ .
10. Stoian, G., & Popirlan, C. (2009). Tehnologii Java pentru dezvolta rea aplicatiilor – Note
de curs. Craiova: Editura Universitaria.
11. Tudose, C. (2016). Inversiunea de control prin Spring Framework. http://ctrl -d.ro/tips –
and-tricks/inversiunea -de-control -prin-spring -framework/ .
12. Winterfeldt, D. (2008). Spring by Example.