Planificarea activității ………………………….. ………………………….. …………………………….. [616993]

Cuprins

Planificarea activității ………………………….. ………………………….. ………………………….. ……………………….. 2
Listă de abrevieri ………………………….. ………………………….. ………………………….. ………………………….. …. 3
Lista figurilor ………………………….. ………………………….. ………………………….. ………………………….. ……… 4
Paper Content ………………………….. ………………………….. ………………………….. ………………………….. ……… 6
1. Stadiul actual ………………………….. ………………………….. ………………………….. ………………………….. …. 12
2. Fundamentare Teoretică ………………………….. ………………………….. ………………………….. ………………. 15
2.1 Introducere în Programarea Orientată pe Obiecte ………………………….. ………………………….. ….. 15
2.1.1 Clasa și Obiectul ………………………….. ………………………….. ………………………….. …………………. 15
2.1.2 Principalele Concepte ………………………….. ………………………….. ………………………….. ………. 15
2.1.2.1 Încapsularea ………………………….. ………………………….. ………………………….. ……………… 15
2.1.2.2 Abstractizarea ………………………….. ………………………….. ………………………….. …………… 15
2.1.2.3 Moștenirea ………………………….. ………………………….. ………………………….. ……………….. 15
2.1.2.4 Polimorfismul ………………………….. ………………………….. ………………………….. …………… 16
2.1.3 Modificatorii de acces ………………………….. ………………………….. ………………………….. ………. 16
2.2 Design Patterns ………………………….. ………………………….. ………………………….. ………………….. 16
2.2.1 Singletone ………………………….. ………………………….. ………………………….. ………………………. 17
2.2.2 Dependency Injection ………………………….. ………………………….. ………………………….. ………. 18
2.2.3 Repository ………………………….. ………………………….. ………………………….. ………………………. 18
2.3 Introducere în Object -Relational Mapping (ORM) ………………………….. ………………………….. …. 19
2.3.1 Entity Framework Code First ………………………….. ………………………….. ………………………… 19
2.4 Persistența datelor ………………………….. ………………………….. ………………………….. ………………. 20
2.5 HTTP ………………………….. ………………………….. ………………………….. ………………………….. …… 21
2.5.1 Metode HTTP ………………………….. ………………………….. ………………………….. …………………. 21
2.5.2 Web API ………………………….. ………………………….. ………………………….. ………………………… 22
2.5.3 AJAX ………………………….. ………………………….. ………………………….. ………………………….. … 23
2.6 Text Analytics API ………………………….. ………………………….. ………………………….. ………………. 23
2.7 AngularJS folosind TypeScript ………………………….. ………………………….. ………………………… 25
2.8 SignalR ………………………….. ………………………….. ………………………….. ………………………….. …. 26
3. Implementarea Arhitecturii ………………………….. ………………………….. ………………………….. ………….. 27
3.1 Implementarea Data Access Layer (DAL) ………………………….. ………………………….. …………. 30
3.2 Implementarea Business Objects ………………………….. ………………………….. ………………………. 36
3.3 Implementarea Business Layer ………………………….. ………………………….. ………………………….. … 38
3.4 Abstracts ………………………….. ………………………….. ………………………….. ………………………….. ….. 39

2
3.5 Implementarea parții Web ………………………….. ………………………….. ………………………….. ………. 39
4. Rezultate experimentale ………………………….. ………………………….. ………………………….. ………………. 43
5. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………. 50
6. Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …… 52
7. Anexe ………………………….. ………………………….. ………………………….. ………………………….. ……………. 54

3.5 Implementarea parții Web ………………………….. ………………………….. ………………………….. ………. 39
4. Rezultate experimentale ………………………….. ………………………….. ………………………….. ………………. 43
5. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………. 50
6. Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …… 52
7. Anexe ………………………….. ………………………….. ………………………….. ………………………….. ……………. 54

2

Planificarea activit ății

Sarcini de lucru Data începerii Număr zile Data sf ârșit
Alegerea temei 14.11.2017 1 14.11.2017
Studiu bibliografic
și acumularea de
cunoștințe legate de
tema proiectului 15.11.2017 84 9.02.2018
Scrierea codului
sursă/
Testarea aplicație/
8.12.2017 111 30.03.2018
Redactarea lucrării
12.04.201 8 89 10.07.201 8
Printarea și legarea 11.07.201 8 1 11.08.2018
Termen de predare 11.07.201 8 2 12.08.2018

3

Listă de abrevieri

Acronim Semnificație
HTML HyperText Markup Language
MVC Model View Controller
JSON Java Script Object Notation
API Application Programming Interface
AI Artificial Intelligence (inteligență artificială)
CRUD Create, Read, Update, Delete
CSS Cascading Style Sheets
DataBase Bază de Date
AJAX Asynchronous JavaScript And XML
REST Representational State Transfer
GUID Globally Unique Identifier (identificator unic global)
FK Foreign Key (cheie străină)
many to many mulți la mulți
one to many unu la mai mulți
OOP Object Oriented Programming (Programarea Orientata pe Obiecte)
PK Primary Key (cheie primară)
SQL Structured Query Language

4
Lista figurilor

Figure 1. Input for review ………………………………………………………………………………………………. 9
Figure 2. Workflow for review processing ……………………………………………………………………….. 11
Figura 2.1. Domeniul modificatoriilor de acces …………………………………………………………………. 16
Figura 2.2. Structura clasei Singleton ……………………………………………………………………………….. 17
Figura 2.3. Structura clasei Singleton folosind lazy initialization ………………………………………… .. 17
Figura 2.4. Arhitectura design pattern -ului Dependency Injection ………………………………………… . 18
Figura 2.5. Definirea unei interfețe IRepository generice ……………………………………………………. .. 19
Figura 2.6. Exemplificarea mapării în c ontainerul UnityContainer ………………………………………… 19
Figura 2.7. Prezentarea modului în care lucrează Entity Framework ……………………………………… . 20
Figura 2.8. Fluxul de lucru al cerintelor HTTP …………….. …………………………………………………… . 22
Figura 2.9. Logica Web Api ……………………………………………………………………………………………… . 23
Figura 2. 10. Structura unui request AJAX …………………………………………………………………………… 23
Figura 2.11. Model de raspuns returnat de Text Analytics API ……………………………………………… .. 24
Figura 2.12. Răspuns returnat pentru un reque st de extragere a cuvintelor cheie …………………….. . 24
Figura 2.13. Răspuns returnat pentru un request de detecția de limbă ……………………………………. .. 24
Figura 2.14. Referințele furnizate pentru cuvintele cheie găsite ……… ……………………………………. .. 24
Figura 2.15. Comunicarea SignalR …………………………………………………………………………………… . 26
Figura 3.1. Arhitectura N -Tier ………………………………….. …………………………………………………….. .. 27
Figura 3.2. Exemplificarea principiul responsabilității unice ……………………………………………….. .. 28
Figura 3.3. Exemplificare open -closed principle ……………. ………………………………………………….. .. 28
Figura 3.4. Exemplificare principiului de substituție Liskov ………………………………………………… .. 29
Figura 3. 5. Extinderea funcționalităților pentru ApplicationDbConte xt …………………………………. .. 30
Figura 3. 6. Extinderea datelor ApplicationUser …………………………………………………………………. .. 30
Figura 3. 7. Repository generic ………………………………………………………………………………………… .. 31
Figura 3. 8. Parolă criptată ……………………………………………………………………………………………….. .. 32
Figura 3.9. Schema algoritmul Secure Hash 3 …………………………………………………………………… … 33
Figura 3.10. Tabela de Users ai aplicației ………………………………………………………………………. …… 33
Figura 3.11. Structura unui GUID …………………………………………………………………………………. …… 34
Figura 3.12. Tabela UserDetails …………………………………………………………………….. ……………….. .. 34
Figura 3.13. Relație one -to-many între un utilizator și rolurile aplicației ………………………………. .. 34
Figura 3.14. Relație one -to-many între un rol și utilizatori …………………………………………………….. . 35
Figura 3.15. Adaugarea rolului de admin unui user …………………………………………………………….. .. 35
Figura 3.16. Tabela de produse ………………………….. ……………………………………………………………. … 35
Figura 3.17. Structura unei Enitități …………………………………………………………………………………….. .36
Figura 3.18. Identificatorul unic al ent ității ………………………………………………………………………… . 36
Figura 3.19. Constrângere a bazei de date ………………………………………………………………………… … 36
Figura 3.20. Structura un ui DTO ………………………………………………………………………………… ……… 37
Figura 3.21. Maparea datelor dintr -o entitate într -un DTO ……………………………………………………. 37
Figura 3.22. Inject are de dependințe ……………………………………………………………………………………. 38
Figura 3.23. Adăugarea unui produs în baza de date …………………………………………………………….. 38
Figura 3.2 4. Contractul serviciului UserService ……………………………………………………. ……………… 39
Figura 3.25. Map ări efectuate în UnityContainer ………………………………………………………………….. 39
Figura 3.26. Controller -ul UserController …………………………………………………………………………….. 40
Figura 3.27. Încărcarea componentelor, modulelor si a controller -elor în pagina de Index ……… … 41

5
Figura 3. 28. Configurarea componentele cu URL -ul corespunzator …………………………………………. … 41
Figura 4.1. Adaugarea unui review …………………………………………………………………………………………. …. 43
Figura 4.2. Executarea requestului de Register pentru mai multe situatii posibile …………………….. …. 43
Figura 4.3. Link -ul de activare primit pe adresa de mail ………………………………………………………………. 44
Figura 4.4. Mesajul de confirmare primit …………………………………………………………………………………. ….. 44
Figura 4.5. Cerere de a schimba parola ……………………………………………………………………….. ………….. …… 44
Figura 4.6. Resetare parolei ……………………………………………………………………………………………………… ….. 44
Figura 4.7. Pagina de produse ……………………………………….. ………………………………………………………… ….. 45
Figura 4.8. Adaugarea unui review pentru un produs ……………………………………………………………….. …. 45
Figura 4.9. Afisarea review -urilor deja existe nte ………………………………………………………………………. …. 46
Figura 4.10. Pagina de statistici ………………………………………………………………………………….. ……………. ….. 46
Figura 4.11. Exportul datelor din diagramele de statistici …………………………………………………………. ….. 46
Figura 4.12. Pagina de management a utilizatorilor . …………………………………………………………………. ….. 47
Figura 4.13. Editarea unui utilizator de către administratorul aplicației ………………………………………. …. 47
Figura 4.14. Editarea datelor personale de către utilizatorul autentificat pe pagină ……………………… …. 48
Figura 4.15. Contactarea administratorului prin chat -ul aplicației ………………………………………………. ….. 48
Figura 4.16. Pagina de chat dedicată administratorului aplicației ……………………………………………….. …. 48
Figura 4.17. Prezentarea modului în care vor fi afișate mesajele ………………………………………………… …. 49

6
Paper Content
1. State of the Art
In the need to create an application that has to be very fast and to give users an impeccable
experience, the most important websites follow the Single Page Application principle, using
technologies such as AngularJS. In this way the user receives only the information he needs so we will
have a much faster application. Handling interactions on the page using AngularJS is enhanced by
TypeScript through which concepts such as classes, interfaces, strongly typed data help programers to
structure the code and a pplications can be more easily deployed. To maintain a user -friendly and
intuitive interface that does not change the look of the app when it is accessed from another device
such as a phone or a tablet we use frameworks like Bootstrap that make responsive applications so
regardless of the display the application page will provide the same functionality and the same design.
Due to the appearance of applications with a different context than a static website, for example a chat
application that requires a use r to see the new messages without refreshing the page, technologies such
as SignalR have been introduced and offer the server the ability to notify the client only when it has
modified data or a message to be sent. Also the demand of smart applications is increasing, to
understand natural language and to implement functionality based on it, Microsoft Azure comes on
the market with Text Analytics API which facilitates the work of the programmer by providing features
such as sentiment analysis, extracting key phrases that help determine the meaning of the processed
text, language detection and also providing references for a more thorough documenting of the
keywords found.
2. Theoretical Fundamentals
2.1 Object Oriented Programing (OOP)
OOP principles are ver y important this days and to understand them it’s important to know
things like what a class is, an object, the most important principle of OOP and why we use acces
modifiers.
Programming based on the concept of “objects” may contain data in form of fields know as attributes
and code in the form of functions, often known as methods. A feature of objects is that object methods
can acces and modify the data elements of the object with which they are associated. A class is a
blueprint of an object that contain s attributes for storing data and methods to perform actions on data
and an object is an instance of the class. All the members of the class have an accessibility level like
private, protected, public, internal and protected internal which controls whether they can be accessed
from other classes in the same assembly or other assemblies.
All the programming languages supporting Object Oriented Programming will be supporting these
four main concepts:
• Abstraction provides a general view of your classes or objects by giving relevant information,
so lets you focus on what the object does instead of how it does it.
• Encapsulation means hiding the internal details of an object, it is used to protect the information
of an object from another object.
• Inheritance i s a process of object reusability, a class includes a property of another class.

7
• Polymorphism means one name and many forms, so one function behaves in different forms
through method like overriding and overloading.
2.2 Design Patterns
2.2.1 Singletone
It’s a design pattern that restricts the instantiation of a single class to a single object. It is useful when
one object is needed to coordinate specific actions in the application.
2.2.2 Dependency Injection
It’s a design pattern through which an object or method can supply the dependencies of another object,
by dependence we understand an object that can be used, a service and by injection passing the
dependencies of an object that uses that service. Injection is done by passing the service inside the
compo nent that requires it. This avoids giving the component access to this service by external methods
or replicating the functionality of the service inside it.
2.2.3 Repository
The Repository Pattern is designed to create an abstract layer between the data a ccess layer and the
business layer of an application. Implementing it helps isolate the app from changes affecting stored
data, reduce code complexity and can facilitate automated testing.
2.3 Introduction to Object -Relational Mapping (ORM)
ORM is used to convert data between incompatible type systems.
2.3.1 Entity Framework Code First
Entity Framework is an open source ORM that allows developers to to work with data in the form of
objects with properties specific to the layer to which they belong without h aving to worry about
database tables and columns that define this information. So we will have a greater degree of data
abstraction and applications that are much easier to maintain. Using Entity Framework with Code First
the database is created based on t he entities of the application so the focus is on the domain of the
application, the corresponding entities and building the business classes that correspond to the needs
of the application, rather than on the realization of the database architecture.
2.4 Data persistence
The most effective ways to maintain user data secure and confidential is to use a database server.
Microsoft SQL Server is a complex package that provides stability and optimally resolves the
concurrent access to data. Application data can be stored on the application's machine and also on a
dedicated server, accessed by the application through the server's IP address, user name and application
password.

8
2.5 HTTP

“The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, and
hypermedia information systems, represent the foundation of data communication for the World Wide
Web. ”
2.5.1 HTTP request methods
HTTP defines methods to indicate the desired action on data resources. When a client sends a request
to the server, part of that request is represented by an HTTP method which specifies to the server what
it's the intention of the client. The most important methods can be summarized by the acronym CRUD
(Create, Read, Update, Delete) the equivalen t of POST, GET, PUT and DELETE methods, but we also
have other methods such as OPTIONS, HEAD, TRACE. SEARCH.
2.5.2 Web API
WebApi applications return directly the data requested by the client, whether it's a browser, desktop
application or other kind of se rvice in a text format such as JSON or XML. Also the access to
resources is done in REST -ful format, being very intuitive for programmers who consume it.

2.5.3 AJAX

AJAX is a set of Web development techniques using many client -side Web technologies to deliver
asynchronous Web applications. It is used to transmit or extract asynchronous data without interfering
with the behavior and the layout of the of the current page, we can dynamically change the data without
having to reload the page.
2.6 Text Analy tics API
It's a service that provides natural language processing methods on the text received and includes four
main functionalities: sentiment analysis, key phrase extraction, language detection, and linking entities
with different points that can provi de additional information about the processed text.
2.7 AngularJS with TypeScript
AngularJS represent a framework for web application developed for JavaScript language and used on
front -end for Single Page Applications. So we will have a web application that interacts with the user
by dynamically rewriting the current page, avoiding reloadig new pages from the server side.
TypeScript is a syntactical superset of Javascript, being an object -oriented language we can use
concepts such as classes, interfaces, inheritance through which we can have a more clear and secure
code structure. Using TypeScript at compile time are generated compilation errors and syntax errors,
so errors will be highlighted before the script run.
By combining AngularJS with TypeScrip t we can create a robust and scalable AngularJS code by
avoiding JavaScript related problems and providing a user -friendly experience.

9
2.8 SignalR
SignalR is a library for ASP.NET developers through which we can add real -time web functionality to
applicat ions. Allows bi -directional communication between the server and the client, the server can
instantly display the content to the connected customers when they become available instead of waiting
for them to make a request.
3. Implementation
To hav e complex application is necessary to chose an arhitecture that satisfy the need of
application, so I chose to use an N -Tier architecture that involves modularization of the application in
the following main parts: Data Acces Layer, Business Logic Layer, P resentation Layer.

To implement this architecture I followed the principles of S.O.L.I.D. This principles help us to
manage most of the design problems so we can move from a code full of dependencies and with a
small degree of encapsulation to a decoupled and encapsulated code.
3.1. Data Access Layer (DAL)
Data Access Layer is responsible for creating the connection with the database, communicating with
it by executing commands like select, insert, update and delete. U sing Code First we create entities
that model the database rather than first create the database and create entities based on that. This layer
has three important parts: ApplicationDbContext is used to manage the interaction between the
application and the database in which our account data is persistent, Configuration which is dealing
with migrations and populating the database with data direct from the application and Repository
which is used to create an abstract layer between data access layer and bus iness layer, it has the
responsibility to communicate with the context of the database, obtain the necessary data, and
communicate it to the business component.
3.2 Business Objects
Business objects represent a fundamental part of an object -oriented N -Tier architecture because a
program can implement classes that usually end up in objects that manage or execute behaviors. These
in general do nothing themselves, only retain a set of instance properties that can be associated with
other business objects resul ting relations between them. To communicate with the database we use
entities that represent an object that contains only data, it doesn't contain functionality, in the database
it is the equivalent of a table. An entity is represented only by those values that are stored in the
database. If you don't store data about something, it's useless to create an entity. Often the data from

10
the front doesn't correspond to what we have in the database or we don't want to expose the entities to
the client for security reasons and for that I used data transfer objects called DTOs that handle data
transfers between different processes . Mapping between entities and DTOs is done manually using
extension methods that represent additional methods by which new methods can be inject ed without
altering, extend by inheritance or compiling classes.
3.3 Business Layer
Business Layer is that part of a program that sets business rules which determines how data can be
created, saved, and modified, in other words it manages business logic. We can consider it as a bridge
between the Web and Data Access Layer, data received from the Web side is passed to the Business
Layer, after being processed will be sent as object to Data Access Layer, this also works in reverse,
data extracted from the database is processed by the services in Business Layer and transmitted to the
Web. The bond between the two components is done by Dependency Injection pattern , to implement
DI is used a Singleton class so always will exist only a current service t hat needs to be handled, and
the mapping of the application contracts with the corresponding services was done in the Dependency
Injection container. Business logic is changing very often, and therefore it's important that this layer
to be very well separa ted from other dependencies , this layer contain only logic for data processing .
3.4 Abstracts
Abstracts contains all the contracts from the application, such as business contracts, data access and
other functionality. The agreement is at an abstract level through which two processes commit
themselves to a communication formula, each respecting its role at its level without complicating the
other one with implementation details
3.5 Web
Presentation Layer is a completely different application served by the se rver in the user's browser .
Web API manages HTTP requests and sends caller a response . It is implemented using the Model –
View -Controller architecture, so the view is represented by a template, what the user sees, the model
represents the information that i nterests the user and the controller links the model to the view,
controls the data that the view receives.
4. Experimental Results
The application is based on text analysis of reviews left by users in order to determine their
feelings about the tested products and to make statistics based on them.
In Figure 1 is presented the place where the user writes a review.

Figure 1. Input for reviw

11
In Figure 2 is presented the entire workflow from the moment a user adds a review until the statistics
are presented.

Figure 2. Workflow for review processing

5. Conclusions
The application approach one important target for product manufacturers and consumers, that
is the satisfaction that brings the products to the users which interact with it. This process is
facilitated by a web application where the products are posted and the people who have tested them
will add reviews that will be processed through natural language algorithms and based on the results
will be created statistics, the content of statistics will be send to the companies that produce the
product. The text processing is done with Text Analytics API, one of Azure's latest AI technologies,
that will process the content of the text by providing scores ranging from zero to one, one being the
most positive, using it the application will provide safe and fast results.

12
1. Stadiul actual
Luând în considerare evoluția actuală a tehnologiilor, consumatorul se lovește de cele mai
multe ori de o gamă largă de produse cu beneficii similare și atunci se pune problema care produs va
satisface cel mai bine necesitățile acestuia . Satisfacerea acestor necesi tăți este un lucru principal atât
pentru o companie care lansează un produs cât și pentru consumator. Astfel înainte de a lansa un produs
pe piață , o companie are nevoie de un feedback de la persoane care au testat produsul pentru a vedea
minusurile și plusurile acestuia sau în cazul în care are deja un produs pe piață dar are nevoie de o
părere a utilizat orilor pentru a vedea care sunt zonele pe care trebuie să insiste pentru urmatoarele
produse. De cele mai multe ori companiile angajează persoane pentru teste, dar dacă ar putea apela la
cineva care se ocupă de asta având persoane specializate pentru fieca re domeniu. Ar fi minuntat,nu?
Tocmai pentru a ușura toată această muncă a apărut conceptul aplicației. Cu ajutorul acesteia toate
firmele care vor să aibă un feedback al persoanelor care vor utiliza produsele lor pot apela la această
aplicație, astfel în urma review -urilor primite de la utizatorii se vor realiza statisticii pe baza
sentimentului acestora legat de produsul testat, statistici care vor ajunge la firma care a lansat produsul.
Această aplicație nu se adresează doar companiilor, consumatorii car e vor să achizițtioneze un produs
dar înainte vor să se documenteze care ar fi cea mai bună alegere pot beneficia de părerile unor
persoane care deja au utillizat produsul astfel putându -și da seama dacă produsul respectiv este ceea
de ce ei au nevoie.În n ecesitatea de a crea o aplicație care trebuie să fie foarte rapidă și care să ofere
utilizatorilor o experiență impecabilă cele mai importante site -uri web folosesc Single Page
Application apelând la tehnologii precum AngularJS. În acest mod utilizatorul p rimește doar
informațiile de care are nevoie oferind o viteză crescută a aplicației. Manipularea interacțiunilor pe
pagină folosind AngularJS este îmbunătățită de TypeScript prin care concepte precum clase, interfețe,
date cu tip predefinit ajută la struct urarea codului putând fi dezvoltate aplicații mult mai ușor iar prin
erorile furnizate la compilare munca programatorului este ușurată. Rapiditatea aplicaților nu este
singurul lucru important pentru utilizatori, aceștia doresc să lucreze cu o interfață pr ietenoasă și
intuitivă, interfață care să nu își schimbe aspectul când aplicația este accesată de pe alt device cum ar
fi un telefon sau o tabletă, pentru asta se apelează la framework -uri precum Bootstrap care face
aplicațiile responsive, astfel indiferen t de dispaly pagina aplicației va furniza aceleași funcționalități
iar design -ul aplicației va fi la fel.
Tehnologia avansează așa de mult încat aproape fiecare aparat electronic va fi connectat la
internet pentru a primi instrucțiuni de la uti lizator, a oferi statistici dar și pentru a comunica între ele
(Internet of things). Pentru ca acest lucru să se întample lumea software trebuie sa își schimbe direcția
de a mai construi site -uri web doar pentru o anumita tehnologie deoarece acum același s et de date
poate fi afișat și prelucrat de o varietate de device -uri pe care rulează diferite sisteme de operare cu
aplicații specifice. Cu alte cuvinte atunci când construim un website sau o aplicație web nu trebuie să
mai creăm un web server care serveșt e doar pagini HTML și resursele aferente. În schimb atunci cand
se construieste partea web trebuie să se aiba în vedere că informațiile care intră și ies pot veni de la
surse foarte diferite. Pentru aceasta marile companii au decis să implementeze comunica rea dintre
server și clienți utilizând un text într -un format standard. Deoarece traficul pe internet pe platformele
mobile este limitat iar costurile sale ridicate, trendul companiilor mari de software este să treacă la un
format standard de fișiere cât m ai economic, astfel se face trecerea de la formatul XML la formatul
JSON. Tot în această direcție de a eficientiza comunicarea dintre aplicațiile de pe device -urile client și
server și de a oferi o experiență cât mai placută utilizatorului s -a creat tehnol ogia prin care serverul
poate notifica clientul, pe mobile numita PushNotifications și Websocket pentru partea de web. Încă
de când s -a creat protocolul HTTP website -urile reprezentau doar o imagine statică a informațiilor de

13
pe server, iar când un utiliza tor vroia să afle dacă s -au modificat erau nevoiți să foloseasca butonul de
refresh al browserului. Datorită apariției de aplicații cu un context diferit față de cel al unui website
static, de exemplu o aplicație de tip chat care presupune ca un utilizator să vadă masajele noi fără a
face refresh la pagină, tehnologia web a fost nevoită să facă schimbări majore în limbajul HTML.
Aplicațiile erau nevoite să verifice în permanență server -ul pentru modificări sau mesaje noi iar această
abordare pentru dispozit ivele mobile reprezenta un consum enorm și inutil de resurse și trafic pe
internet fiind foarte costisitor pentru clienți. De aceea acum există tehnologii precum SignalR care
oferă serverului posibilitatea să notifice clientul doar în momentul în care are date modificate, sau un
mesaj de transmis. Astfel aplicații moderne care au inclus capabilități de comunicare directă cu un
reprezentant al companiei sunt foarte eficiente atât din punct de vedere al stabilității, vitezei cât și a
traficului pe internet.
În ultimul timp se dezvoltă tot mai mult idea de inteligență artificială și întelegerea limbajului natural
care reprezintă un subset important al inteligenței artificiale și care constă în prelucrarea limbajului
natural pentru a înțelege cu exactitate ceea ce textul propune și extragerea semnificației ascunse. Este
folosit pentru a realiza boți precum Siri, Google Assistant, Alexa etc dar și pentru a implementa
functionalități care depind de un text, cum ar fi analiza de review -uri, detectarea mesajelor ned orite și
redirectarea spre Spam etc. Microsoft Azure vine pe piață cu Text Analytics API care ușurează munca
programatorului oferind funcționalități precum analiza sentimentului, extragerea frazelor cheie care
ajută la a determina semnificația textului pro cesat, detecție de limbă și furnizarea de referințe pentru o
documentare mai amanunțită a cuvintelor cheie găsite, astfel dezvoltarea de aplicații “inteligente”
devine din ce în ce mai accesibilă. La începuturile internetului când se crea o aplicație, date le cu care
lucra erau ținute ori în fișiere text ori într -o bază de date locală de exemplu SQLite. Cum nevoia de
comunicare și împărtășirea informației a crescut s -au dezvoltat aplicații stand alone care se ocupă cu
persistența datelor într -un mod optim și oferă posibilitatea ca de pe alte mașini să se facă managementul
informației stocate prin protocoale de comunicare precum HTTP. Mai ales că acum este nevoia tot mai
mare ca un set de date să fie disponibil nu doar pentru aplicația inițială ci pentru o mul titudine de alte
aplicații auxiliare.
Pentru aplicații performante nu este suficient doar să folosești tehnologii de ultimă oră, este important
ca de la început să existe un plan care descrie un set de aspecte și decizii care sunt importante pentru
aplicație fiind luate în considerare cerințe de performanță, securitate, organizarea sistemului, cum
comunică parțile de sistem între ele, dacă există dependințe externe, riscurile care trebuie luate în
considerare și tehnologiile de implementare. Astfel a rhitectura trebuie să fie gandită pe termen lung, o
soluție care este valabilă acum, va fi valabilă și mai târziu? Pentru asta se urmăresc anumite
functionalități cum ar fi ca soluția software să fie scalabilă și să suporte orice tip de creștere, să aibă
o performanță ridicată și să ruleze rapid, să fie ușor de a aduce modific ări dar și de a adăuga noi
funcționalități iar menținerea să fie facilă. Pentru a obține toate aceste lucruri a aparut principiul de
design pattern prin care se pot capta anumite ide i ale aplicației rezultând concepte orientate pe obiecte
prin care se definește comportamentul unui grup de obiecte. Astfel prin aplicarea de design pattern -uri
pentru designul și dezvlotarea aplicației vor apărea îmbunătățiri, în primul rând oferă o modal itate de
a rezolva probleme legate de dezvoltarea software utilizând o soluție testată, soluție care facilitează
dezvoltarea unor componente cu un grad de cuplaj minim, crează un sistem mai ușor de înțeles și
menținut, iar modelele de design pattern ușurea ză comunicarea între developeri, aceștia pot vizualiza
imediat designul la nivel înalt atunci când se face referire la numele unui design pattern utilizat pentru
a rezolva o anumită problemă când se discută despre proiectarea sistemului.

14
Această aplicație va avea o stocare persistentă a datelor folosind Microsoft SQL Server, partea de
Server va fi contruită în .NET utilizând o arhitectura n -Tier prin care sunt decuplate parți ale aplicației
folosind design pattern -uri precum Dependency Injection, Singleton si Repository care vor face ca
aplicația să fie fiabilă, ușor de menținut și dezvoltat. Pentru o rapiditate crescută și o experiență placută
a utilizatorului pe partea de client se va folosi principiul de Single Page Application folosind AngularJS
împreună cu TypeScript. Iar pentru menținerea unei interfețe prietenoase și responsive se va folosi
Boostrap. Comunicarea între client și server va fi în format JSON. Pentru a implementa
funcționalitatea de chat se va apela la SignalR iar pentru partea de procesar e a limbajului natural,
concretizat în review -urile primite de la utilizatori se va folosi Text Analytics API. Astfel vorbim de o
aplicație cu tehnologii performante și o arhitectură care permite creșterea complexității indiferent în
ce direcție am merge.

15
2. Fundamentare Teoretică
2.1 Introducere în Programarea Orientată pe Obiecte
2.1.1 Clasa și Obiectul
În programarea orientată pe obiecte întalnim foarte des noțiunea de clasă și obiect, dar ce reprezintă
de fapt acest lucru? O definiție pen tru aceasta ar fi urmatoarea: „Programarea orientată pe obiecte
(OOP) este o paradigmă de programare bazată pe conceptul de "obiecte", care poate conține date sub
formă de câmpuri, adesea cunoscute ca atribute și cod sub formă de funcții, adesea cunoscute ca
metode. O caracteristică a obiectelor este că metodele obiectului pot accesa și modifica adesea
câmpurile de date ale obiectului cu care sunt asociate. Programele sunt realizate din obiecte care
interacționeaza între ele. Există o varietate semnificativ ă de noțiuni, dar cele mai importante sunt
bazate pe definiția de clasă, adică obiectele sunt instanțe ale unei clase, care de obicei determină tipul
lor ”[1]. Cu alte cuvinte clasa reprezintă un tip de obiecte din lumea reală de exemplu calculator care
conține procesor, memorie RAM, placă video, iar obiectul este materializarea clasei de exemplu
calculatorul pe care lucrez eu: Lenovo cu procesor I7 3200MHz, memorie 2Gb RAM și placă video
Gforce 9600GTX .
2.1.2 Principalele Concepte
Principalele concepte au fost punctate foarte bine în cartea „Beginning C# Object -Oriented
Programming 2nd ed. Edition ” de Dan Clark dup ă cum urmează :
2.1.2.1 Încapsularea
Prin încapsulare întelegem faptul c ă atributele și metodele unei clase sunt grupate în înteriorul acesteia.
Prin acest principiu putem ascunde date interne despre un obiect sau cum funcționează acesta. Este
foarte utilă pentru protejarea informațiilor, astfel utilizatorii vor vedea doar ce v rem noi s ă vadă în
funcție de modificatorii de acces folosiți.
2.1.2.2 Abstractizarea
Abstractizarea se concentrează pe ce poate face un obiect, nu pe modul în care ajunge să facă asta. Îți
oferă un model de clasă generică furnizând informațiile importan te. Aceasta ascunde procesul de
realizare a obiectului și prezintă informații utile despre acesta într -un mod ușor de înțeles.
2.1.2.3 Moștenirea
Îți oferă posibilitatea să creezi o nouă clas ă care reutilizează sau extinde comportamentul definit într –
o altă clasă, clas a care este mo ștenită se numește clasă părinte iar cea care moștenește clasă copil. În
acest fel putem evita codul duplicat astfel având un proiect mult mai ușor de întreținut. Putem
restricționa daca dorim ca o clasă să nu fie clasă părinte folosind atributul sealed pri n care o clasă nu

16
poate fi moștenită sau putem stabili ca o clasă să poată fi folosită doar ca și clasă părinte, să nu poată
fi instanțiată, folosind atributul abstract.
2.1.2.4 Polimorfismul
Așa cum îi spune și numele presupune că un obiect are mai multe forme. Cel mai simplu mod de a
obține acest lucru este folosind moștenirea și aplicând metodele de upcasting care presupune procesul
de cast a unui obiect de tip copil la un obiect de tip parinte și downcasting care presupune operația
inversă, mai precis se face cast asupra unui obiect de tip părinte la un obiect de tip copil. Prin
polimorfism înțelegem faptul că mai multe clase implementează aceeași metodă în mai multe moduri.
Avem doua tipuri de polimorfism: polimorfism dinamic acesta se execută la run time folosind atributul
de overriding prin care putem definini mai multe metode cu aceași denumire și același numar de
parametrii dar care funcționează în mod diferit, astfel sub -clasele pot suprascrie metode deja existente
în clasa părinte modificând impl ementarea acestora și polimorfism static, care se execută la compile
time folosind motoda de overloading prin care avem același nume pentru o metodă dar numarul, tipul
parametriilor și implementarea diferă.
2.1.3 Modificatorii de acces
Pentru fiecare clasă și membrii ai acesteia se poate specifica ce nivel de acces vor avea pentru alte
clase folosind modificatorii de acces: public cu ajutorul căruia atributele sau metodele pot fi accesate
de orice clasă din același namespace sau din alt namespace, private prin care atributele sau metodele
pot fi utilizate doar în interiorul clasei care le definește, protected atributele sau metodele pot fi utilizate
doar în interiorul clasei sau în clasele derivate din aceasta, internal informațiile dintr -o clasă pot fi
accesate doar de clasele care fac parte din același namespace cu clasa respectivă, protected internal
atributele și metodele pot fi accesate atât de clasele din același namespace cât și de clasele derivate din
această clasă care se găsesc în alt namespace con form autorului Dan Clark în cartea Beginning C#
Object -Oriented Programming 2nd ed. Edition.

Figura 2.1. Domeniul modificatoriilor de acces [2]
2.2 Design Patterns
După cum spune Steven John Metsker în cartea Design Patterns în C# design pattern reprezintă o
soluție generală, reutilizabilă pentru o problemă frecvent întâlnită într -un context în proiectarea
soluțiilor software. Este un șablon care poate fi utilizat în sit uații diferite pentru a rezolva o problemă,
modelele de design pattern reprezintă cele mai bune practici pe care un programator le poate utiliza
pentru a rezolva probleme comune atunci când proiectează o aplicație, modele de design pattern
precum Singleton , Dependency Injection și Repository vor fi prezentate în rândurile ce urmează.

17
2.2.1 Singletone
Singleton reprezintă un software design pattern care restricționează la instanțierea unei singure clase
rezultând astfel un singur obiect. Este util când este nevoie de un singur obiect care să coordoneze
acțiuni specifice în aplicație. Astfel cererile din contextul respectiv vor fi exectutate mult mai rapid și
eficient având un singur obiect care trebuie tratat. Acesta ascunde constructorul clasei, ea nemaiputâ nd
fi niciodată instanțiată din afara ei. Ideea acestui pattern este faptul că face clasa în sine responsabilă
de instanța sa iar pentru a returna o singură instanță a clasei dipunem de metoda getInstance() care
poate fi accesată ușor folosind numele clase i Singleton și numele metodei
ClasăSingleton.getInstance(). Astfel pentru implementarea acestui pattern trebuie să ne asigurăm că
avem o singură instanță a clasei Singleton și că avem un acces global la aceasta, acest lucru se rezolvă
prin a declara const ructorul private și furnizarea unei metode care returnează referința la instanță. În
general instanța este stocată ca o variabilă statică privată iar atunci când variabila este inițializată,
instanța este creată.

Figura 2.2. Structura clasei Singleton
Singleton poate folosi lazy initialization prin care evităm să inițializăm obiectul daca nu îl utilizăm,
astfel se reduce cantitatea de resurse folosite iar pentru a avea o aplicație cât mai sigură putem folosi
lazy verification prin care verificăm dacă există deja un obiect în uz dacă nu există putem face
instanțierea, astfel sunt evitate multe erori.

Figura 2.3. Structura clasei Singleton fo losind lazy initialization

18
2.2.2 Dependency Injection
Reprezintă un design pattern prin care un obiect sau o metodă poate suplini dependințele unui alt
obiect, prin dependință înțelegem un obiect care poate fi folosit, un serviciu iar prin injectare, pasarea
dependințelor unui obiect care folosește serviciul respectiv. Injectarea se face transmițând serviciul în
interiorul componentei care îl necesit ă. Astfel evităm să dăm componentei acces la acest serviciu prin
metode externe sau să replicăm funcțion alitatea serviciului în interiorul acesteia. Acest procedeu de
transmitere este esențial pentru respectarea acestui design pattern, astfel utilizarea valorilor produse în
cadrul componentei prin metode noi sau statice este interzisă, aceasta trebuie să acc epte valori injectate
din exterior. Prin injectare reușim să decuplăm p ărți ale aplicației, astfel schimb ările din servicii nu
aduc cu sine și schimbarea componentelor în care sunt injectate, sau invers. Componentele în care vor
fi injectate dependințe vor avea acces doar la interfața care definește funcționalitățile serviciului, astfel
vor ști doar numele interfeței nu și cum este implementată. Pentru a implementa acest design pattern
definim un injector care crează și injectează serviciile pe care o compo nentă le necesită, aceasta acceptă
obiecte în loc să le creeze, nu va mai fi dependentă de modul în care sunt create obiectele. Din cele
spuse mai sus putem deduce patru funcționalități necesare: un serviciu de care să ne folosim, o
componentă care depinde de serviciu, o interfa ță care definește cum se poate folosi serviciul și un
injector care este responsabil de injectarea dependințelor , pattern reprezentat foarte bine în cartea
Dependency Injection în .NET de Mark Seemann.

Figura 2.4. Arhitectura design pattern -ului Dependency Injection [3]

2.2.3 Repository
Repository Pattern este destinat pentru a cr eea un strat abstract între stratul de acces la date și stratul
de business a unei aplicații. Implementarea acestuia ajută la izolarea aplicației de modificarile efectuate
asupra datelor stocate, reduce complexitatea codului și poate facilita testarea autom ată. În principiu
furnizează o abstractizare. Obiectele client trimit cerințe spre componenta Repository, aceasta poate
insera, modifica, selecta sau șterge datele din baza de date, în urma cerințelor venite. Există mai multe
moduri de a implementa acest d esign pattern, putem avea c âte un Repository pentru fiecare entitate
care trebuie stocată sau care trebuie să furnizeze date pentru stratul prezentare, marele beneficiu al
acestei abord ări este faptul că nu trebuie să implementezi metode de care nu ai nevo ie, dar aceasta
soluție va duce la existența unui cod duplicat si o complexitate mare a aplicației. Pentru a rezolva
aceste probleme este recomandat să se creeze o interfață simplă și generică IRepository care va conține
semnaturile pentru operațiile CRUD cât și alte funcționalități pentru Repository, există posibilitatea
constrâng erii tipuri lor de date ce funcționează pentru acest Repository

19

Figura 2.5. Definirea unei interfețe IRepository generice
Avantajul acestei abord ări spre exemplu este că va asigura o interfață comună pentru a lucra cu oricare
din obiectele aplicației. După ce interfața este creată se poate realiza componenta care implementează
această interfață. Astfel putem crea Repository -uri pentru orice tip de date fără să mai fie nevoie de a
rescrie cod. Pentru ca un obiect să aibă acces la Repository este necesară menționarea dependinței între
aceștia, astfel se folosește un container unde se fac map ările putând specifica un element de tipul
IRepository<Item > care în container va fi mapat cu implementarea unui Repository<Item>.

Figura 2.6. Exemplificarea mapării în containerul UnityContainer
2.3 Introducere în Object -Relational Mapping (ORM)
ORM reprezintă o tehnică de programare pentru conversia datelor între sisteme de tip
incompatibile folosind un limbaj de programare orientat pe obiecte. Acest lucru creeaz ă de fapt o „bază
de date virtuală a obiectelor”.
2.3.1 Entity Framework Code First
După cum prezintă Julia Lerman în cartea „Programming Entity Framework” Entity Framework este
un open source ORM care permite programatorilor să lucreze cu date sub formă de obiecte cu
propietății specifice stratului din care fac parte, cum ar fi datele unui utilizator din stratul de prezentare,
fară a fi nevoiți să se preocupe de tabelele și coloanele bazei de date care definesc aceste informații.
Astfel vom avea un grad mai mare de abstractizare a datelor și aplicații mult mai ușor de menținut.
Acesta ne pune la dispoziție două abordări pentru a crea o entitate, modelul tabelelor din baza de date,
Code First și Database First, prin care mai întâi se realizează designul ba zei de date și pe baza acestuia
se construiesc entitățile. Entity Framework Code First inițial nu are nevoie de o bază de date deoarece
Code First o poate crea iar în cazul în care aceasta deja există Code First o va popula cu tabele. Astfel
atenția se con centrează asupra domeniului aplicației, entitățile corespunzatoare acestuia și construirea
claselor de business care corespund necesităților aplicației decât pe realizarea arhitecturii bazei de date.
Code First are mai multe componente, prima componentă es te reprezentată de entitățile care sunt
responsabile cu modelarea tabelelor bazei de date corespunzătoare obiectelor de business.
Interacțiunea dintre aceste obiecte și baza de date se realizează prin contextul Entity Framework, Code
First adaugă în preala bil un constructor de modele care inspectează clasele care vor fi gestionate de
context având un set de reguli prin care determină modul în care interacționează clasele între ele și
care ar fi corespondența în baza de date. Putem modifica baza de date dacă modificăm entitățile și
folosim Cod First Migration o abilitate a Entity Framework prin care se compară clasele entitate cu
structura bazei de date și se efectuează modific ările necesare astfel încât cele dou ă să fie echivalente.
Cu alte cuvinte fluxul de lucru utilizând Code First este de a crea clasele de domeniu, configurarea
acestora folosind Fluent -API sau data annotation și configurarea schemei bazei de date folosind
migrarea automată sau migrarea manuală.

20

Figura 2.7. Prezentarea modului în care lucrează Entity Framework [4]

2.4 Persistența datelor
Unul dintre cele mai eficiente moduri de a menține datele utilizatorilor sigure și confidențiale este
folosirea unui server de baz ă de date. Microsoft SQL Server este un pachet complex ce oferă stabilitate
și rezolvă într -un mod optim accesul concurent la date. Astfel datele aplicației pot fi ținute atât pe
mașina unde se află aplicația cât și pe un server dedicat, fiind accesat de c ătre aplicație prin adresa de
ip a serverului, username și parola dedicate aplicației.
Microsoft SQL Server este un sistem de management al bazelor de date relaționale , această idee este
foarte bine ilustrată în cartea „Introducing Microsoft SQL Server 2014 ”de Ross Mistry și Stacia
Misner , care presupune existența unei structuri de date, operatori care acționează asupra structurii și
restricții de integritate. Structura de date este formată dintr -un domeniu care reprezintă un ansamblu
de valori caracterizat printr -un nume specific, tabele care sunt un sub -ansamblu al domeniului având
nume caracteristice și atribute care aparțin aceleași clase de entități, fiecare tabelă conține atribute
care reprezintă coloanele unei tabele, o tabelă este construită din mai multe tupluri, un tuplu este de
fapt o linie dintr -o tabel ă, fiecare tuplu poate fi identificat printr -un atribut de identificare Key(cheie)
sau un ansamblu de mai multe atribute de identificare unice, există mai multe tipuri de chei, cele mai
importante fiind cheile primare(Primary key) care reprezintă unul sau mai multe câmpuri care
identifică un tuplu într -un tabel, acestea nu pot fi nule fiind idexate și cele externe(Foreign key) care
definesc o relație între coloanele dintre două tabele din baza de da te astfel putem grupa datele în funcție
de necesitățile aplicației. De multe ori cand interogăm o tabelă din baza de date nu avem nevoie de
toate câmpurile acesteia, pentru a ușura acest proces se încearcă gruparea datelor în funcție de anumite
particulari tăți. De exemplu avem o tabelă Users cu date generale despre utilizatori, dar pentru fiecare
utilizator dorim să avem și anumite informații care nu dorim să fie afișate de fiecare data iar pentru
asta creăm tabela de UserDetails unde avem date specifice pe ntru fiecare utilizator, astfel cheia primară
din tabelul de Users va fi folosită ca și cheie externă în tabela de UserDetails, putând accesa această
tabelă doar cand avem nevoie de aceste informații. Operatorii relaționali utilizează algebra relațională
pentru a manipula conținutul bazei de date (SELECT, JOIN, INTERSECT, DIFFERENCE etc.) iar
restricțiile de integritate furnizează niște funcționalități care ne permit să impunem restricții pentru o
funcționare mai bună a bazei de date.
Pentru a restructura b aza de date în conformitate cu niște forme normale și pentru a reduce redundanța
datelor se folosește procesul de normalizare, care presupune organizarea coloanelor și a tabelelor

21
pentru a ne asigura că dependințele sunt impuse în conformitate cu constrâng erile de integritate. Acest
proces se realizează fie printr -un proces de sinteză, crearea unui nou design al bazei de date, fie printr –
un proces de descompunere care presupune îmbunatațirea unui design al bazei de date deja existent.
Există mai multe tipur i de forme normale dar cele mai importante sunt primele patru. Prima formă
normal ă presupune ca fiecare camp într -o bază de date să cuprindă numai o valoare atomică și fiecare
înregistrare să fie definită astfel încat s ă fie identificată într -un mod unic p rintr-o cheie primara, a doua
formă condiționează ca fiecare rând al unei tabele s ă fie dependent de totalitatea cheii primare, daca
nu acele elemente care depind numai de o parte a cheii primare vor fi separate în tabele diferite, a treia
formă presupune o relație în forma doi în plus faptul că orice atribut trebuie să depindă exclusiv de
cheia primară și nu de alte atribute. Mai specific nu trebuie s ă existe dependințe tranzitive ex: A -> B
-> PK nu este în forma normală trei deoarece A depinde de PK prin B. Forma a patra normală se aplică
atunci când avem o cheie primară compusă din cel puțin trei atribute. Ea presupune ca fiecare prim
atribut să fie în dependen ță funcțională cu al doilea atribut adică fiecare prim atribut să determine un
singur al doilea atribut și niciodată mai mult de unul: X -Y-Z cheie primară compusă pentru fiecare X
să existe un singur Y cu care să formeze o pereche unică XYZ. În cazul în care se încalcă forma și
există mai multe chei primare cu acceași pereche XY pentru mai multe val ori Z, tabela se împarte în
două tabele astfel că prima tabelă are cheie primară XY iar a doua XZ.
Un foarte mare avantaj al serverelor de bază de date este acela că fac singure managementul
concurenței acțiunilor asupra bazei de date. Asta înseamnă că da că doi utilizatori vor să modifice
aceeași resursă în același timp serverul nu doar că le poate executa fără să arunce erori dar oferă și
opțiuni developerului prin care poate refuza acțiunea unuia dintre utilizatori în funcție de prioritatea
fiecăruia.
SQL a ajuns să fie limbajul standard pentru managementul bazelor de date relaționale datorită
portabilității și ușurinței de a programa în el. Deși mulți developeri inclusiv cei care l -au creat au fost
sceptici încă înainte ca limbajul să devină popular plus faptul că timpul de execuție este aproape dublu
față de rivalii săi SQL a dovedit că este cea mai bună op țiune pentru a crea și manipula baze de date
în producție.
2.5 HTTP
“Hypertext Transfer Protocol este un protocol de aplic ație pentru sistemele informatice distribuite și
colaborative, reprezintă fundamentul comunicării de date pentru Word Wide Web ” [5].
2.5.1 Metode HTTP
HTTP definește metode pentru a indica acțiunea dorită asupra unor resurse de date. Atunci când un
client trimite o cerere la se rver, o parte din acea cerere este reprezentată de o metodă HTTP, prin care
menționează serverului care este intenția clientului , această idee este susținută de David Gourley, Brian
Totty, Marjorie Sayer, Anshu Aggarwal, Sailu Reddy în HTTP: The Definitive Guide (Definitive
Guides) 1st Edition.
. Cele mai importante metode pot fi rezumate la acronimul CRUD (Create, Read, Update, Delete)
echivalentul metodelor POST, GET, PUT și DELETE dar avem și alte metode cum ar fi OPTIONS,
HEAD, TRACE. SEARCH etc.
GET -folosit pentru a returna doar informații despre resurse, nu se pot face modificări asupra acestora.
Prin această metodă parametrii se trimit în URL iar formatul se numește QueryString. Un dezavantaj
este faptul că lungimea URL -ului este de maxim 255 de ca ractere, astfel cantitatea de informație
trimisă fiind foarte limitată.

22
POST -această metodă cere serverului să accepte entitatea inclusă în cerere ca un suborodant al resursei
web identificate de UR L, cu ajutorul acestuia ad ăugăm sau modificăm date. Spre deosebire de metoda
GET, prin POST se pot trimte parametri i atât în URL prin QueryString cât și în BODY -corpul
requestului, această componentă acceptând atât format text, hexa cât și binar.
PUT -la fel ca și POST are o entitate inclusă, dar cu acesta putem doar modifica resurse deja existente,
nu putem adăuga.
DELETE – ștergerea resurselor specificate
TRACE – reflectă cererea primită astfel încat un client să poată monitoriza eventuale modificari ap ărute
pe serverele intermediare.
OPTIONS – returnează metod ele HTTP pe care serverul le acceptă pentru adresa URL.
HEAD – solicită un răspuns la fel ca metoda GET, dar f ără să conțină și corpul mesajului în componenta
de răspuns.

Figura 2.8. Fluxul de lucru al cerin țelor HTTP [6]

2.5.2 Web API
Spre deosebire de website -urile clasice care la un request returnează o pagină Web(fișiere de tip
HTML, JS, CSS, etc.) aplicația WebApi returnează direct datele cerute de c ătre client fie el browser,
aplicație desktop sau alt fel de serviciu într -un fo rmat text precum JSON sau XML. De asemenea
modul de accesare a resurselor se face în format REST -ful, fiind foarte intuitiv pentru programatorii
care o consumă. Format REST -ful presupune c ă toate căile de acces să aibă la bază un context urmat
de entitate și sub-entitățile sale iar modul de accesare făcându -se folosind doar metode de request(GET,
POST) de ex: account/user/userdetails.
Web API aduce cu sine mai multe avantaje fa ță de MVC cum ar fi serializarea internă prin care
returnarea datelor este mult mai ușoar ă, fără a exista o metodă prop rie de extensie sau controlerul să
devină dependent de un framework de serializare, funcții de ajutor pentru rezultatul acțiunilor astfel
putem folosi func ții precum Ok(), NotFound(), InternalServerError() pentru rezu ltatul obținut având
un cod mai ușor de citit și eliminând anumite posibilități în cazul erorilor apărute. Pentru abstractizare
se folosește IHttpActionResult prin acest procedeu se obțin rezultat abstracte iar prin rutarea atributului
WebAPI se face mult mai ușor configurația de rutare o abordare corectă a acestei funcționalități găsim
în ASP.NET Web API 2: Building a REST Service from Start to Finish 2nd ed. Edition de Jamie Kurtz
și Brian Wortman.

23

Figura 2.9. Logica Web Api [7]
2.5.3 AJAX
AJAX reprezintă un set de tehnici de dezvoltare Web folosind multe tehnologii Web pe parte de client
pentru a realiza aplica ții Web asincrone. Folosind AJAX putem transmite sau extrage date, asincron,
fără a interfera cu comportamentul și aspectul paginei curente, putem schimba datele în mod dinamic
fără a fi necesară reînc ărcarea paginii. Pentru transmisia și primirea datelor se folosește în general
formatul JSON. AJAX este o combinație de mai multe tehnol ogii, HTML și CSS sunt folosite pentru
a se ocupa de designul interfeței cu utilizatorul, aceasta poate fi modificată dinamic de JavaScript
permițând utilizatorului să interacționeze cu noile informații, cererile către server se realizează în
JavaScript ex ecutând call -uri AJAX , astfel paginile Web pot afișa noul conținut fără a actualiza pagina.

Figura 2.10. Structura unui request AJAX
2.6 Text Analytics API
Conform documentației furnizate de Microsoft Azure Text Analytics API este un serviciu în
cloud care furnizează metode de procesare a limbajului natural asupra unui text primit și include patru
funcționalități principale: analiza sentimentului, extragerea expresiilor cheie, detectarea limbii și
legarea entităților de diferite pun cte care pot furniza informații suplimentare despre textul procesat.
API-ul este susținut de resursele Serviciilor Cognitive furnizate de Microsoft și cuprinde o colecție de
machine learning și algoritmi AI.
Prin analiza sentimentelor putem determina senti mentul utilizatorului legat de topicul abordat în textul
primit, acesta poate fi pozitiv sau negativ. API -ul returnează un scor între 0 și 1, 1 fiind cel mai pozitiv,
pentru fiecare text procesat. În funcție de limba selectată acesta poate analiza și încad ra orice text
primit returnând un răspuns imediat aplicației în așteptare.

24

Figura 2.11. Model de răspuns returnat de Text Analytics API [8]

Extragerea expresiilor cheie reprezintă extragerea automată a expresiilor care identifică punctele
principale de interes.

Figura 2.12. Răspuns returnat pentru un request de extragere a cuvintelor cheie [9]

Putem aplica funcția de detecție a limbii pentru aproximativ 120 de limbi, această funcționalitate
identifică limba în care este scris te xtul și furnizează un cod pentru acea limb ă precum și un scor prin
care indic ă corectitudinea limbajului folosit de utilizator.

Figura 2.13. Răspuns returnat pentru un request de detecți e de limbă [10]

Prin interconectarea entităților putem găsi referințe sau mai multe informații depre expresiile cheie
găsite, astfel putem găsi definiții sau linkuri către pagini web care abordează aceste subiecte.

Figura 2.14. Referințele furnizate pentru cuvintele cheie găsite [11]

25
2.7 AngularJS folosind TypeScript
AngularJS reprezintă un framework pentru aplicațiile web dezvoltat pentru limbajul JavaScript și
folosit pe partea de front -end a aplicațiilor de tipul Single Page Application, aplicație web care
interacționează cu userul prin rescriere a dinamică a paginii curente, evitând încărcarea unor noi pagini
de pe partea de server. AngularJS îți permite să extinzi HTML -ul cu atribute adiționale, f ăcând
experiența utilizatorului cu interfața mult mai pl ăcută. Astfel Angular citește pagina de HTML care are
atribute de tag customizate, interpretează aceste atribute ca directive prin care leagă par ți din pagina
HTML cu un model reprezentat de variabilele JavaScript a căror valori pot fi setate din cod sau pot fi
populate de un JSON dinamic. Pentru a a vea o aplicație cât mai ușor de dezvoltat se urmărește
decuplarea client -side de server -side astfel putând avea o dezvoltare în paralel a ambelor parti, dup ă
cum știm pe partea de server avem mai multe design pattern -uri pe care le putem folosi pentru a avea
o aplicație mai ușor de menținut. Ceea ce aduce Angular este posibilitatea de a implementa pe client –
side design pattern -uri, astfel folosește design patternul Model -View -Controller (MVC) prin care
separă partea de prezentare de date și logica compone ntelor. Astfel view reprezintă template -ul
aplicației și se axează pe modul în care afișezi datele, formatul acestora etc., model furnizează
informația care îl interesează pe utilizator iar contro ller-ul face legătura dintre model și view,
controlează ce d ate primește ce view. Un alt design pattern folosit de Angular este Dependency
Injection pentru rezolvarea dependințelor, el oferă trei metode în aceasta directie: Factory, Module si
Controller. Indiferent de metodă pentru a folosi o componentă sau un serv iciu extern trebuie specificat
în descrierea modulului sau a controllerului un string asociat cu acel serviciu sau componentă. La run
time acel string este înlocuit cu o instanță a acelui serviciu de obicei injectat într -o variabilă de tip
interfață implem entată de către servicu, astfel controller -ul care îl folosește este complet decuplat de
implementarea lui. Acest framework trece de la abordarea clasică one -way data -binding la two -way
data-binding prin care modelul din Angular este interconectat cu parte a de HTML în ambele direcții,
atunci când modelul sau datele din model se modifică Angular updatează și HTML -ul astfel ca
utilizatorul să vadă modificarile. Iar când HTML -ul este modificat de catre utilizator printr -un observer
pattern Angular este notific at de modific ări și updatează modelul din controller astfel ca datele să poată
fi transmise pe server daca este nevoie.
Cu cât codul de JavaScript crește, cu atât devine mai dificilă menținerea și reutilizarea lui, iar faptul
că nu este un limbaj orientat pe obiecte și nu verifică erorile de compilare nu este recomandat să fie
folosit ca tehnologie de vârf a serverului. Pentru a rezolva aceste probleme apare TypeScript care
reprezintă un superset sintactic Javascript, fiind un limbaj orientat pe obiect. Deo arece este un superset
de JavaScript TypeScript adoptă blocurile de baza de la JavaScript, prin urmare trebuie să cunoaștem
doar limbajul JavaScript pentru a utiliza TypeScript, tot codul de TypeScript este convertit în
echivalentul său JavaScript pentru e xecutare, prin urmare programele deja existente în JavaScript sunt
valide și pentru TypeScript. Prin utilizarea acestui superset la compilarea codului sunt generate erorile
de compilare și erorile de sintaxă astfel erorile vor fi evidențiate înainte ca scr iptul să fie rulat. O altă
caracteristică importantă este faptul că putem specifica tipul variabilelor folosite (number pentru a
reprezenta valori numerice, string pentru caractere, boolean pentru a reprezenta valori ile booleene și
any pentru orice tip de variabilă sau în cazul în care pot exista mai multe posibilități), dar cea mai
importantă funcționalitate pentru TypeScript r ămâne faptul că suportă programarea orientată pe
obiecte, astfel putem folosi concepte precum clase, interfețe, moștenire etc. prin care putem avea o
structurare mult mai clară, avantajoasă și sigur ă a codului această idee este susținută de Steve Fenton
în cartea Pro TypeScript: Application -Scale JavaScript Development 1st Edition .
Astfel combinând AngularJS cu TypeScript putem crea un cod AngularJS robust și scalabil evitând
problemele generate de JavaScript și furnizând o experiență placută utilizatorului.

26
2.8 SignalR
SignalR este o librărie pentru dezvoltatorii ASP.NET prin care putem adăuga funcționalitați web în
timp real aplicațiilor. Acesta beneficează de WebSocket și de un HTML5 API care permite
comunicarea bi -direcțională între server și client, serverul poate afișa instantaneu conținutul clienților
conectați în momentul în care devin disponibili în loc să aștepte ca aceștia să facă un request. SignalR
beneficează de mai multe tipuri de transport, alegând tot timpul calea cea mai avantajoasă. Cu ajutorul
acestuia putem adăuga orice tip de funcționalitate web în timp real apli caților ASP.NET, cea mai
cunoscută este chat -ul dar putem face mult mai multe cu acesta cum ar fi aplicații pentru monitorizare,
aplicații colaborative(editarea simultană a documentelor), actualizări de date și formulare în timp real,
jocuri în timp real e tc. SignalR oferă un API simplu pentru a crea un apel server -client prin care
apelează funcțiile JavaScript în browserul clientului din codul .NET de pe server, acesta include de
asemenea API pentru gestionarea conexiunilor (conectare, deconectare) putând trimite mesaje
simultane tuturor clienților conectați sau unor clienți specifici și gruparea acestora.

Figura 2.15. Comunicarea SignalR [12]

API-ul SignalR conține două modele de comunicare între client și server: conexiune persistentă și Hub.
Conexiunea persistentă este recomandată în cazul în care trebuie specificat formatul mesajului
transmis, dezvoltatorul preferă să lucreze cu un model de mesagerie și de expediere decât cu o invocare
la distanță sau av em deja o aplicație care deja utilizează un model de mesagerie și este portată să
utilizeze SignalR. În rest este recomandat să folosim Hub -uri, hub -ul se bazează pe API -ul de conectare
și permite clientului și serverului să își transmită metode de la unul la altul în mod direct, astfel clienții
pot apela metode de pe server la fel de ușor ca metodele locale și invers, iar ca parametrii în metode
putem transmite valori cu un tip deja definit. Fluxul de lucru al hub -urilor este urmatorul: atunci când
serveru l cere o metodă de pe client, un pachet care conține numele și parametrii metodei care trebuie
apelată este transmis peste transportul deja activ (când un obiect este transmis ca parametru este
serializat folosit JSON). După clientul caută numele metodei î n metodele definite pe partea clientului,
iar dac ă există o potrivire metoda va fi executată utilizând datele parametrilor deserializați.

27
3. Impl emen tarea Arhitecturii

Figura 3.1. Arhitectura N -Tier [13]
Pentru a avea o bună dezvoltare a produsului am decis să urmez bunele practici pentru
construirea unei aplicații complexe, astfel încât am ales să f olosesc o arhitectură N -Tier care presupune
modularizare a aplicației în urmatoarele p ărți principale: Data Acces Layer, Business Logic Layer,
Business Objects, A bstracts , Presentation Layer .
Pentru implementarea acestei arhitecturi am urmat principiile S.O.L.I.D. Principiile S.O.L.I.D ne ajută
să gestionăm majo ritatea problemelor de proiectare astfel putem trece de la un cod plin de dependințe
și cu un grad de încapsulare mică la un cod decuplat și încapsulat. S.O.L.I. D este dezvoltat de Robert
C. Martin în cartea Design Principles and Design Patterns și reprezintă practic principalele cinci
principii de proiectare orientate pe obiecte, aceste principii combinate ajută programatorul să dezvolte
programe ușor de întreținut și complexe, astfel va exista un cod ușor de refractorizat care va putea fi
adapta t în funcție de necesități. S.O.L.I.D este un acronim pentru urmatoarele:
1.S – Principiul responsabilității unice
2.O -Open -closed principle
3.L -Principiul de substituție Liskov
4.I -Principiul de segregare a interfețelor
5.D -Dependency Inversion Princi ple

28
1. Principiul Responsabilității Unice: „O clasă ar trebui să aibă o singură responsabilitate și ar trebui
să existe un singur motiv pentru a schimba această clasă” [14]. Cu alte cuvinte, toate metodele dintr -o
clasă ar trebui sa fie legate de un singu r scop. De exemplu în Figura 3.2 este prezentată clasa
UserService care are metode ce țin doar de managementul userilor, nu conține metode legate de
managementul produse lor, comentarii lor etc.

Figura 3.2. Exemplificarea principiul responsabilității unice
Astfel Principiul Responsabilității Unice ne oferă o soluție bună de a identifica clasele necesare în faza
de proiectare a aplicației și de a gândi toate situațile posibile care pot schimba clasa respectivă.
2. Open -closed principle „Obiectele sau ent itățile ar trebui să fie deschise pentru extindere dar închise
pentru modificare” [15].
Cu alte cuvinte o clasă ar trebui să fie ușor de extins/îmbunătățit fără ai schimba logica. Pentru acest
lucru se folosește moștenirea.

Figura 3.3. Exemplifica re open-closed principle

29
În Figura 3.3. ApplicationDbContext moștenește clasa IdentityDbContext astfel clasa
IdentityDbContext va răm âne nemodificată și va oferi minimul de tabele din baza de date și toate
facilitățile de bază pentru comunicarea cu baza de date iar ApplicationDbContext va avea
implementate noi func ționalități în funcție de necesitățile aplicației.
3. Principiul de substituție Liskov : „Orice clasă copil poate fi folosită în locul clasei p ărinte acționând
în același mod fără a aduce modific ări” [16]. Bazându -ne pe acest principiu ne asigurăm c ă
implementarea claselor derivate să nu afecteaze comportamentul clasei de bază, cu alte cuvinte
obiectele să poată fi înlocuite de subtipurile lor. Codul să fie scris în așa fel încât o clasă care
moște nește o altă clasă să poată înlocui clasa de bază fără să îi schimbe comportamentul. Pentru
soluționarea acestei probleme se folosesc interfețe care se axează pe o anumită parte a logicii, astfel în
Figura 3. 4. clasa UserService va moșteni doar IUserService nu și metodele care țin de managementul
produselor.

Figura 3. 4. Exemplificare principiului de substituție Liskov
4. Principiul de segregare al interfețelor: „Un client nu ar trebui niciodată obligat să implementeze o
interfață pe care nu o folosește sau să depindă de metode pe care nu le utilizează” [17]. La fel ca și
clasele, interfețele ar trebui să aibă un scop specific, nu ar trebui să fi forțat să implementezi o interfa ță
dacă obiectul nu împărtășește același scop sau daca are metod e pe care nu le utilizează. Astfel fiecare
interfață ar trebui să aiba un scop precis iar metodele care o definesc să fie specifice. Iar în cazul în
care un obiect are mai multe privilegii va putea moșteni mai multe interfețe sau mai multe interfețe
mai mi ci pot fi grupate într -o interfață mai mare iar clasele pot moșteni această interfață putând utiliza
și metodele din celelalte interfețe.

30
5. Dependency Inversion Principle : „Entitățile nu trebuie să depindă fizic unele de altele ci doar la
nivel de abstractizare. Modulul de nivel înalt nu trebuie să depindă de modulul de nivel scăzut, dar
trebuie să depindă la nivel de abstractizare ” [18]. Cu alte cuvinte se încearcă evitarea codului strâns
interconectat, nu se mai depinde la nivel de obiect în schim b se depinde la nivel de abstracțiuni
deoarece cu cât aplicația va crește, cu atât va fi mai greu de menținut arhitectura. Daca o clasă ar
depinde fizic de o altă clasă și s -ar schimba ceva în aceasta, clasa derivată ar avea și ea de suferit
modificări. A cest principiu ne ajută să avem o decuplare între diverse p ărți de cod ale aplicației.
Pentru decuplarea componentelor din aplicație am folosit Dependency Inversion. Aplicăm
Dependency Injection folosind ca și Dependency Injection Container soft -ul Unity C ontainer. Astfel
toate componentele Business din aplicație sunt complet decuplate și orice modificare ar apărea nu
afectează celelalte componente în niciun fel. Componentele comunică între ele cu ajutorul interfețelor
iar inițializarea lor se face doar pri n Unity Container astfel în momentul în care unei componente i se
schimbă codul sau trebuie o altă componentă asemanătoare folosită în locul ei singura modificare este
făcută ori asupra componentei ori maparea interfeței în Unity cu noua componentă.
3.1 Implementarea Data Access Layer (DAL)
Baza de date este creată folosind Entity Framework cu Code -First. Folosind Code First creăm
entități care modelează baza de date în loc de a crea mai întai baza de date și pe modelul acesteia să
modelăm entit ățile. Data Acces Layer este responsabil pentru crearea conexiunii cu baza de date,
comunicarea cu aceasta executând comenzi de selecție, inserare, modificare și ștergere. Acest strat are
trei părți importante: ApplicationDbContext, Configuration si Repository.
ApplicationDbContext este folosit pentru a gestiona interecțiunea dintre aplicație și baza de date în
care datele noastre de cont sunt persistente, este important de menționat că această clasă nu moștenește
DBContext specific pentru Entity Fram ework ci moștenește IdentityDbContext. Cu alte cuvinte
ApplicationDbContext moștenește dintr -un DataBase context predefinit făcând parte din
Microsoft.AspNet.Identity.EntityFramework care conține clasele de bază ale Code First pentru
sistemul de identitate .

Figura 3. 5. Extinderea funcționalități ilor pentru ApplicationDbContext

Figura 3. 6. Extinderea datelor Application
Putem observa în Fig ura 3. 5. că această clasă moștenește din IdentityDbContext cu un tip generic
ApplicationUser. ApplicationUser moștenește (Figura 3. 6.) de la o clasă IdentityUser și reprezintă
unitatea de identitate de bază pentru gestionarea conturilor în ASP.NET iar pe lângă propietățile
furnizate de IdentityUser putem extinde clasa ApplicationUser prin adăugarea de proprietăți proprii,
care vor fi reflectate în baza de date generată. Folosim DbSet<> pentru a comunica bazei de date faptul
că dorim să creăm o tabelă cu a numite proprietăți date de modelul entității care se află în DbSet<>. Iar

31
metoda onModelCreating() ne oferă posibilitatea să aducem modificări proprietăților tabelei înainte
ca aceasta să fie creată în baza de date.
În partea de Configuration ne ocupăm de migrări și de popularea bazei de date cu date direct din
aplicație. Pentru migrări avem setat pe true proprietatea AutomaticMigrationsEnabled ceea ce
înseamnă că baza de date va fi updatată automat cu modificările făcute modelului de fiecare dată când
se execută aplicația. Făcând override peste metoda Seed putem insera date în tabelele bazei de date din
aplicație, este util pentru teste sau în cazul în care avem niște notații prestabilite, cum ar fi asignarea
de roluri.
Repository se utilizează pentru a cr ea un strat de abstractizare între data access layer și business layer,
acesta are responsabilitatea de a comunica cu contextul bazei de date, a obține datele necesare și a le
comunica componentei de business , având injectat contextul bazei de date , care e ste de fapt oglinda
bazei de date . Pentru a nu avea un Repository implementat pentru accesul la fiecare tabelă în parte
folosim un Repository generic (Figura 3. 7.), operațiile acestuia pot fi folosite asupra tuturor tabelelor
din baza de date și execută op erații generice asupra contextului, acoperă atât opeațiile CRUD (creare,
citire, updatare și ștergere) dar și alte funcționalități.

Figura 3. 7. Repository generic
Pentru a crea baza de date cu tabelele aferente este necesar ca înainte să stabilim exact ce date vrem să
cuprindă aplicația și relațiile care se stabilesc între ele, de la început lucrurile trebuie să fie clare și
concrete deoarece cu cât aplicația devine mai complexă relațiile dintre tabele pot deveni confuze. Se
recomandă aces t lucru deoarece o structură defectoasă a bazei de date poate duce la scăderea
performanțelor servic iilor furnizate de aplicație. Folosind IdentityDbContext vom avea pentru început

32
tabelele legate de contul unui utilizator, este foarte important de preciza t că parolele în tabela de Users
nu vor fi salvate în clar ci vor fi criptate, un lucru foarte important pentru securitatea utilizatorilor.

Figura 3. 8. Parol ă criptată
Există mai multe modalități de cripta re:
Hashing :
Reprezintă un tip de criptare prin care informația odată criptată nu mai poate fi decodată iar lungimea
informa ției criptate este fix ă. Acest tip de criptare este util atunci când nu mai ai nevoie să cite ști data
stocată ci doar s ă o verifici. Este foarte util pentru stocarea parolelor, în loc să stochezi parola în clar
stochezi vari anta codată direct. Iar atunci c ând cineva încearcă să își introducă parola, se aplică același
algoritm de codare asupra informației primite iar rezultatul se compară cu datele din baza de date, în
cazul în care se potrivește se permite autentificarea .
Salting :
Funcționează prin adăugarea unei valori extra la începutul și sfârșitul informației de criptat, extinzând
astfel lungimea informației codate. Pot apărea probleme în cazul în care cineva descoperă valoarea
pentru codare deoarece ar trebui doar să o adauge la începutul și sfârșitul fi ecărui cuvânt de atac, pentru
a evita asta se folosesc valori aleatorii, câte una pentru fiecare parolă.
Parcursul pentru înregistrarea și autentificarea într -un sistem de codare: utilizatorul își crează un cont,
parola nu se salvează în clar ci direct cod ată în baza de date iar atunci când utilizatorul încearcă să își
introducă parola se aplică același algoritm de codare asupra informației primite iar rezultatul se
compară cu parolele din baza de date, dacă găsim o potrivire utilizatorului îi este garantat accesul iar
în caz contrar va primi un mesaj prin care i se comunică faptul că parola este invalidă. Deoarece am
folosit SQL Server 2017 algoritmul folosit pentru criptarea parolei este SHA -3 fiind cel mai complex
algoritm de criptare la care se mai adaug ă și Salt pentru a întări complexitatea criptării și a oferi o mai
bună protecție.
SHA -3 (algoritmul Secure Hash 3) este cel mai recent membru al familiei de standarde de algoritmi
Secure Hash, reprezintă un subset al criptografiei, al primitivelor criptog rafice Keccak. Keccak constă
într-o abordare denumită „construcția bureților” care se bazează pe o funcție aleatorie sau o permutare
aleatorie și permite introducerea (absorți a) a oricărei cantități de date și ieșirea (stoarcerea) a oricărei
cantități de d ate, în timp ce acționează ca o funcție pseudo -randomică în ceea ce privește intrările
anterioare, având astfel o flexibitate crescută. SHA -3 utilizează „construcția bureților”, în perioada de
introducere a informației aceasta este structurată în blocuri d e mesaje într -un subset al stării care apoi
vor fi transformate ca un ansamblu utilizând o funcție de permutare f. În faza de ieșire blocurile sunt
citite din același subset al starii alternate cu funcția de transformare de stare f. Dimensiunea părții de
stare care este scrisă și citită se numește „rată”, iar marimea parții care este neatinsă de intrare/ieșire

33
se numește „capacitate”, aceasta determină securitatea schemei. Nivelul maxim de securitate este
jumătate din capacitate. Având un șir de biți de in trare, o funcție de permutare f care operează pe
blocuri de biți cu lățime b, o rată r și o lungime de ieșire d rezultă capacitatea c și construcția de burete
Z rezultând un șir de biți Z de lungime d.

Figura 3. 9. Schema algoritmul Secure Hash 3
O scurtă prezentarea a tabelelor cu câmpurile aferente:
Una dintre cele mai importante tabele este tabela de Users prezentată în Figura 3. 10.

Figura 3. 10. Tabela de Users a aplicaț iei

Am să vorbesc despre principalele câmpuri din această tabelă, în primul rând avem campul de E -mail
care reprezintă adresa utilizatorilor care se înregistrează în aplicație, PasswordHash despre care am
vorbit în rândurile de mai sus, UserName care repr ezintă numele utilizatorului și am considerat ca
valoare pentru acesta adresa de e -mail a fiec ărui utilizator deoar ece o adresă de e -mail este unică astfel
vom evita situațile în care utilizatorii să aibă același nume. Datorită faptului că există aplicații robot
care pot completa un formular de înregistrare, hackerii pot folosi un astfel de robot să creeze utilizatori
și să atace aplicația și baza de date. Iar pe lângă acest lucru dorim ca aplicația să conțină doar conturi
a căror adresă de e -mail chiar există. Pentru a evita aceste probleme de securitate și a face o aplicație
fiabilă am creat un mecanism care atunci cân d un user își crează un cont cu o adresă de e -mail aplicația
îi crează un cont temporar și îi asociază un cod unic TokenGuid în baza de date iar apoi trimite un e –
mail adresei cu care s -a creat contul conținând un mesaj de întâmpinare și un link care conț ine acel

34
token către o pagină de validare a contului. Astfel userul atunci când va citi e -mailul va fi instruit în
cazul în care chiar a dorit înregistrarea pe această aplicație să urmarească link -ul de validare. În
momentul în care persoana accesează pagi na de activare userul asociat este setat ca și valid în baza de
date (IsValidate=true) și va primi un mesaj cum ca îi este validat contul și va fi redirectat către pagina
de autentificare .
TokenGuid reprezintă un identificator unic global și este o identit ate unică pentru o entitate, diferite
tipuri de obiecte au diferite tipuri de GUID, baza de date are un câmp de 16 octeți pentru a stabili un
identificator unic. GUID -urile sunt defapt numere mari, care sunt în principal garantate ca fiind unice,
sunt de o bicei pe 128 de biți , în Figura 3.11. avem reprezentat un GUID în hexazecimal

Figura 3.1 1. Structura unui GUID

Logica din spatele GUID -urilor este faptul că alegând un număr aleator de dimensiuni mari este puțin
probabil ca cineva să îl ghiceasc ă și nu sunt legate de un anumit tip de produs, șansele să avem
duplicate pe aceași mașină sunt foarte mici dar în cazul în care vorbim de două sau mai multe mașini
aceste șanse cresc iar GUID -ul nu mai reprezintă alternativa cea mai bun ă.
Pentru necesitățile aplicației câmpurile furnizate nu ne satisfac în totalitate nevoile , am ales să
extindem datele tabelei adăugând UserDetails_Id ca și Foreign Key în tabela de UserDetails, acest
UserDetails_Id reprezintă ID -urile din tabela de UserDetails unde fiecare utilizator va putea s ă își
completeze informații personale cum ar fi adr esă, nume și prenume, acest lucru este opțional și ramâne
la latitudinea utilizatorului sau a administratorului aplicației.

Figura 3.1 2. Tabela UserDetails

O parte foarte im portantă a aplicației este faptul că avem privilegii pentru anumiți utilizatori, cum ar
fi administratorul aplicației care poate avea acces la anumite pagini la care alți utilizatori nu au acces.
Acest lucru este posibil cu ajutorul tabelelor de Roles, Use rRoles și Users. Între tabelele de Roles și
Users există o relație many -to-many, adică un rol poate fi asignat la mai mulți utilizatorii dar și un
utilizator poate avea mai multe roluri. Rolurile existente sunt stabilite din aplicație și nu pot fi
modifica te din exterior, iar leg ătura între tabele este facută în tabela UserRoles în funcție de Id -urile
aferente.

35
În Figura 3.1 3 un utilizator va avea asignate mai multe roluri:

Figura 3.1 3. Relație one -to-many între un utilizator și roluri le aplicației

În Figura 3.1 4 un rol va avea mai mulți utilizatori asignați:

Figura 3.1 4. Relație one -to-many între un rol și utilizatori

Figura 3.1 5. Adăugarea rolului de admin unui user
Astfel în Figura 3.1 5 adresa root@mail.com va avea privilegiu de admin al aplicației . O altă tabelă
importantă este tabela de produse care va avea o relație one -to-many cu tabela de comentarii, un produs
având mai multe comentari i. Iar tabela de Reviews va avea o legatură one -to-many cu tabela de Users
astfel un utilizator va avea review -uri pentru mai multe produse.

Figura 3.1 6. Tabela de produse
Un câmp foarte important în tabela de comentarii este Sentiment care reprezintă impresia utilizatorului
despre produsul pentru care a făcut review -ul. Acesta este generat în urma analizei de text și are valori
cuprinse între 0 si 1. Scorurile apropiate de 1 indică un sentiment pozitiv iar scorurile apropiate de 0
indică un sentiment negativ.

36
3.2 Implementarea Business Objects
Business objects reprezintă o parte fundamentală într -o arhitectură N -Tier orientată pe obiect.
Întrucât un program poate implement a clase care de obicei se termină în obiecte care gestionează sau
execută comportamente. Acestea în general nu fac nimic în sine ci doar rețin un set de propietăți de
instanță, care pot fi asociate cu alte business objects rezultând astfel relații între ac estea.
Vom începe prin a vorbi de entitățile proiectului.

Figura 3.1 7. Structura unei Enitități
O entitate este un obiect care există, acesta nu conține func ționalitate, ea conține doar date. Acestea în
baza de date reprezintă echivalentul unei tabele, în administrarea bazei de date o entitate poate fi un
singur lucru sau un obiect, datele fiind stocate în funcție de aceste entități. O entitate este reprezentată
doar de acele valori care sunt stocate în baza de date. Daca nu veți stoca date desp re ceva anume, nu
are rost să creați o entitate într -o bază de date. Entitățile au atribute care definesc informațiile despre
entitate care trebuie stocate, o entitatea poate să nu aib ă nici un atribut sau mai multe atribute care vor
fi valabile doar pentr u entitatea respectivă. Un atribut are îmbunăt ățiri suplimentare cum ar fi domeniul
și cheia, domeniul va furniza valorile posibile ale atributelor, fiecare atribut va avea o singură valoare,
care poate fi necompletată sau text, număr, etc. Este foarte imp ortant ca o entitate să aibă o cheie (key)
care reprezintă un identificator unic al entității, cheile fiind unice pentru fiecare înregistrare în baza de
date.

Figura 3.1 8. Identificatorul unic al entității
De asemnea entitățile pot avea constrângeri care pot aplica reguli asupra atributelor cum ar fi faptul că
anumite atribute nu au voie să ramână necompletate sau să satisfac ă anumite condiții precum unicitatea
în tabelă etc. Și de asemnea pot face legătura înt re entități folosind constrangerea de Foreign Key
(cheie străină) care reprezintă un camp într -o tabel ă care este Primary Key(cheie primară) în altă tabelă.
Tabele care conțin chei străine se numesc tabele copii, iar tabelele care conțin cheia primară se n umesc
tabele părinte.

Figura 3.1 9. Constrângere a bazei de date

37
Dacă am expune entitațile bazei de date clientului acesta ar avea acces direct la baza de date, ceea ce
nu este indicat deoarece de multe ori structura datelor de pe front nu corespund cu ce avem în baza de
date sau nu dorim ca utilizatorul să vadă anumite informații. Pentru a avea o oglindă a datelor care
vin sau dorim să fie afișate pe partea de front am creat obiecte pentru transfer de date numite DTO –
uri. Un DTO este un obiect care transportă date între diferite procese. Unul dintre motivele pentru care
sunt folosite este faptul c ă între procese comunicarea se face de obicei apelând interfețe la distanță.
Având în vedere necesitatea reducerii duratei unui apel între client și server și numarul acestora pentru
a avea o aplicație cât mai rapidă avem ca soluție utilizarea DTO -urilor care agregă date care ar fi fost
transferate prin mai multe apeluri, dar care este deservit doar de un singur apel. Obiectul de transferat
date nu are nici u n comportament și sunt obiecte simple care nu trebuie să conțină nici o logică de
business. Acestea sunt cel mai des utilizate de stratul business într -o aplicație cu arhitectură N -Tier
pentru a transfera datele între serviciile stratului și partea de web. Principalele beneficii sunt reducerea
cantit ății de date care se transmite, putem ascunde date din baza de date la care utilizatorii nu ar trebui
să aibă acces, putem omite anumite date din baza de date pentru a reduce dimensiunea datelor
transmise și nu în cele din urma decuplează serviciile de baza de date.

Figura 3. 20. Structura unui DTO
De cele mai multe ori structura entităților nu este unu la unu cu cea a DTO -urilor astfel este necesară
o mapare. Putem opta pentru o maparea automată sau o ma pare manulă. În această aplicație maparea
între entit ăți și DTO -uri se face manual utilizând metode de extindere. Metodele de extindere sunt după
cum le sugerează și numele metode suplimentare, prin care putem injecta metode noi fără a modifica,
deriva sau recompila clasele. Putem spune că extinde funcționalitatea unui tip deja existent și poate fi
apelată în același fel în care sunt apelate și metodele instanței, primul parametru al metodei specifică
tipul pe care funcționează metoda precedat de modificato rul „this”

38

Figura 3.2 1. Maparea datelor dintr -o entitate într -un DTO
3.3 Implementarea Business Layer
Stratul de business reprezintă aceea parte din program care stabilește regulile de afaceri din
lumea reală , prin care determină modul în care datele pot fi create, salvate și modificate. Cu alte cuvinte
gestionează logica de afaceri, de a executa un flux de evenimente, conține regulile pe care o companie
dorește s ă le pună în aplicare. Acesta este o punte de le gătură între partea de Web și Data Access Layer.
Toate datele primite de pe partea de Web sunt pasate stratului de afaceri, după ce au fost prelucrate
vor fi trimise sub formă de obiecte către Data Acces Layer, acest lucru funcționează și în sens invers,
datele extrase din baza de date sunt prelucrate de serviciile din stratul de afaceri și sunt transmise către
Web. Logica de business se schimbă foarte des și de aceea este important ca acest strat să fie foarte
bine separat de alte dependințe. În acest stra t nu se p ăstrează informație ci doar logică de prelucrare a
datelor.
O să luăm ca exemplificare serviciul de Products din acest strat, în constructorul serviciului este
injectat Repository -ul folosind Dependency Injection astfel vom putea utiliza toate met odele puse la
dispozi ție de acesta. Pentru implementarea pattern -ului de Dependency Injection am folosit o clas ă
Singleton, în felul acesta având doar un serviciu curent care trebuie tratat.

Figura 3.2 2. Injectare de dependințe
O să evidențiez acest lucru prin a exemplifica Figura 3.2 3 care prezintă procesul de adăugare a unui
produs, de pe partea de front va veni un DTO de tip ProductDetailsDto, noi dorim să trimitem o entitate
ProductDetails în baza de date și nu un DTO, fiecare produs are un cod unic de identificare, în cazul
în care acesta nu este null însemnă că avem deja un produs cu acest cod, îl extragem din baza de date
folosind metoda GetAll().FirstOrDefault(it => it.Code == product.Code) care o să ia toate datele cu
acel cod, dar după cum am menționat mai sus codul este unic astfel vom avea un singur produs. Dup ă
ce aveam produsul respectiv realizăm maparea prin care datele din baza de date vor fi înlocuite cu cele
din DTO iar după se va apela metoda de Update() care va updata datele p entru entitatea respectivă. În
cazul în care codul este null se va genera un cod pentru produs, se va realiza și aici o mapare între
entitate și DTO iar mai apoi entitatea va fi inserată în baza de date. După ce a avut loc una dintre cele

39
două situații pre zentate se vor salva toate modific ările. La fel ca acest exemplu există o multitudine de
metode care satisfac fiecare necesitate în parte.

Figura 3.2 3. Adăugarea unui produs în baza de date
3.4 Abstracts
Componenta abstracts conține toate contractele din aplicație fie contracte de business, ac cesul
la date sau alte funcționalități.

Figura 3.2 4. Contractul serviciului UserService
Aceste contracte sunt folosite în toată aplicația acolo unde este nevoie de funcționalitate și reprezintă
înțelegerea dintre două sau mai multe componente, întelegere a este la nivel abstract prin care două
procese se obligă la o formulă de comunicare, fiecare respectându -și rolul la nivelul ei f ără să o
îngreuneze pe cealaltă cu detalii de imple mentare.
3.5 Implementarea p ărții Web
Web API managerează cererile HTTP primite și trimite un răspuns apelantului, acestea sunt de
fapt niște clase derivate din clasa System.Web.Http.ApiController, trebuie să conțină Controller în
denumirea lor iar toate m etodele controller -ului sunt considerate metode de acțiune. În continuare am
să prezint modul prin care se face legătura între partea de business, abstract și DAL și anume printr –

40
un container UnityContainer unde se vor face mapări între contracte și servicii sau între contracte și
Repository.

Figura 3.25. Map ări efectuate în UnityContainer
Tinând cont de faptul că nu dorim a se executa mai multe funcționalități în același timp ne vom folos i
de principiul Singleton prin care o s ă avem o singură instanță de clasă. Metodele acestei clase sunt
folosite în Controllerele Web API ale proiectului Web.

Figura 3.2 6. Controller -ul UserController
După cum se poate vedea în Figura 3.2 6. UserController este derivat din ApiController care reprezintă
clasa de bază Web API și include diferite metode de acțiune care sunt reprezentative pentru metodele
de request HTTP GET, POST, PUT și DELETE. În funcție de URL și metoda de request HTTP a
cerinței primite, Web API decide care controller Web API și metodă trebuie folosită. În cazul în care
nu dorim să avem metode care încep cu verbe HTTP putem stabili proprile noastre rute folosind
atributul Route unde stabilim ce denumire să aibă metoda pentr u URL. Am să exemplific pentru
controllerulde User metoda AddOrUpdate, URL -ul va arăta în felul următor
http://localhost:6251/api/User/AddOrUpdate astfel folosind RoutePrefix(“api/User”) stabilim că de
fiecare dată când un URL va avea această denumire în componen ță va fi redirectat sper acest controller
iar AddOrUpdate va conduce spre metoda care are această rută implementată. După cum vedem
metoda prin care adăugăm sau modificăm un utilizator folosește containerul de Dependency Injection,
apelând metoda getInstance() se va instanția serviciul mapat interfeței IUserService, astfel vom putea
folosi metodele acestuia. Un atribut foarte important de menționat este cel de autorizare c are va permite

41
accesul la nivel de controller sau metodă doar unor anumiți utilizatori. În unele cazuri este necesar să
avem validări suplimentare pentru datele care țin de contul unui utilizator astfel am folosit
ModelState.IsValid, acesta indică dacă a f ost posibilă o corelare corectă a valorilor primite din request
cu modelul și dacă au fost încălcate regulile de validare specificate. Atunci când avem un utilizator
autentificat avem doar niște informații specifice de autentificare, în cazul în care avem nevoie de mai
multe informații este necesar să știm id -ul utilizatorului, pentru asta folosesc Principal care reprezintă
contextul de securitate în care rulează codul și împreună cu Identity returnează identitatea asociată
acestuia.
Stratul de prezentare e ste o aplicație complet diferită, servită de către server în browserul utilizatorului.
Acesta este implementat folosind arhitectura Model -View -Controller, astfel partea de view este
reprezentată de un template, ceea ce vede utilizator, partea de model este reprezentată de informaț iile
care îl interesează pe utilizator iar controllerul face legătura dintre model și view, controlează datele
pe care le primește view -ul. Deoarece am decis ca abordarea pentru aplicația de front să fie Single
Page Application am ales să folosesc AngularJS framework pentru partea de front -end a aplicațiilor
Web, asta presupune că aplicația să conțină o singură pagină HTML (index.html), în care se încarcă
diferite date în funcție de ce acțiuni execută utilizatorul pe pagină. Inițial la accesarea site -ului se va
servi de la server pagina de home, aceasta este o pagină virtuală la fel ca toate paginile despre care o
să vorbim în capitolele ce urmeaz ă deoarece ele sunt de fapt ni ște template -uri HTML care se încarc ă
în singura pagina HT ML pe care o avem.

Figura 3.2 7. Încărcarea componentelor, modulelor si a controlle r-elor în pagina de Index
Fiecare template face parte dintr -o componentă care mai conține declarația modulului din care face
parte și un controller care se ocup ă de managementul logicii și a datelor. Astfel inițial va fi înc ărcată
componenta de home dar pentru diferite acțiuni ale utilizatorului se pot încărca alte componente
precum cea de produse sau de login. Decizia prin care încărcăm o componentă se face prin ruta(url -ul)
pe care îl accesează userul. Aceasta configurare url -componentă se face în fișierul app.config.ts

42

Figura 3.2 8. Configurarea componentel or cu URL -ul corespunzator
Datorită faptului că fiecare componentă lucrează cu date , fie le aduce de pe server sau le trimite, am
creat un serviciu de requesturi care se ocupă exclusiv cu acest tip de acțiuni.
Folosindu -mă de capabilitatea Dependency Injection din Angular am injectat serviciul în fiecare
controller al componentelor astfel făcând decuplarea între partea de business și cea de date a aplicației.
Menționez că partea de injectare se face nu direct cu obiectul serviciu ci folosind o interfa ță pe care
serviciul o implementează astfel făcând agnostică func ționarea serviciului de c ea a controllerului și
orice modificare făcuta uneia dintre clase nu o afectează pe cealaltă. Pentru persistența datelor în
aplicație am ales să folosesc Local Storage deoarece este mult mai eficientă decât cookies și ține de
ultima tehnologie HTML5. În or ice moment apl icația îi oferă utilizatorului posibilitatea de a comunica
direct cu administratorul site -ului printr -un chat. Pentru realizarea acestuia am folosit tehnologia
SignalR care dă posibilitatea nu doar clientului(în cazul nostru browserul) să inițieze request -uri la
server dar și serverul să inițieze apeluri către client astfel eliminând paradigma protocolului HTTP prin
care doar clientul poate apela serverul pentru comunicare.

43
4. Rezultate experimentale
În această parte am să prezint funcționalitățiile aplicației și interacțiunea cu utilizatorul.
După cum am spus aplicația se bazează pe analiza de text a review -urilor lăsate de utilizatori pentru a
putea determina sentimentul acestora față de produsele testate.

Figura 4.1. Adaugarea unui review
Pentru a putea adăuga review -uri este necesar să devii membru, astfel primul pas pe care o persoană
trebuie să îl facă este să își creeze un cont, acest lucru se face accesând pagina de Register și
completând niște câmpuri de date, acestea vor fi populate cu o adresă de mail validă, parolă și
confirmare parolei, câmpul de confirmare parolă trebuie să fie identic cu cel de parolă. Toate aceste
câmpuri au validări specifice, în primul r ând nu poate rămâne nici un câmp necompletat, adresa de
mail introdusă trebuie să fie validă având un format specific iar parola trebuie să respecte o anumită
complexitate, să aib ă o dimensiune mai mare de 6 caractere, să conțină cel puțin o literă mare, u n
număr și un caracter special. În cazul în care nu se respectă condițiile de validare vor fi afișate mesaje
specifice prin care se va comunica problema ap ărută. După ce s -au completat aceste date se poate apăsa
butonul de Register prin care utilizatorul v a fi stocat în baza de date.

Figura 4.2. Executarea requestului de Register pentru mai multe situa ții posibile
Ne dorim ca aplicația să conțină doar conturi a căror adresă de e -mail chiar există. Pentru a evita
această problemă d e securitate și a face o aplicație fiabilă am creat un mecanism care atunci când un
utilizator își crează un cont cu o adresă de e -mail aplicația îi crează un cont temporar iar apoi trimite
un e-mail adresei cu care s -a creat contul conținând un mesaj de î ntâmpinare și un link către o pagină
de validare a contului. Astfel utilizatorul atunci când va citi emailul va fi instruit în cazul în care chiar
a dorit înregistrarea pe această aplicație să urmarească link -ul de validare (Figura 4.3)

44

Figura 4.3. Link -ul de activare primit pe adresa de mail

Figura 4.4. Mesajul de confirmare primit
Dupa ce un utilizator și -a creat contul și l -a validat se poate autentifica pe aplicați e. În cazul în care nu
își mai amintește parola de autentificare poate opta pentru op țiunea de Forget password (Figura 4.5)
unde își poate reseta parola, acesta trebuie să completeze câmpul de E -mail address cu adresa de mail
a cărei parolă vrea să o schim be.

Figura 4.5. Cerere de a schimba parola
Va primi un link de resetare pe adresa de mail care îi va furniza o pagină (Figura 4.6.) pentru
schimbarea parolei.

Figura 4.6. Resetare parolei
După ce avem un utilizator autentificat acesta pe lângă beneficiile pe care le are ca simplu utilizator
primește autorizarea de a putea lăsa comentarii produselor prezentate în aplicație, produse care se
găsesc pe pagina de home.

45

Figura 4.7. Pagina de produse
Pentru a adăuga un review acesta trebuie să acceseze pagina produsului respectiv, unde găsim detalii
tehnice despre produs și putem vizualiza review -urile deja existente. În căsuța destinată review -urilor
utilizatorul va putea împărtăși experiența lui cu p rodusul, putând specifica minusurile și plusurile
acestuia și dacă l -ar recomanda

Figura 4.8. Adaugarea unui review pentru un produs

46
Review -urile postate vor rămâne pe pagina produsului astfel persoanele interesate de acest produs vor
beneficia de păreri argumentate venite din partea unor utilizatori care au interacționat cu produsul.

Figura 4. 9. Afișarea review -urilor deja existente
După ce un review a fost adăugat pe pagină, conținutul acestuia este procesat și pe baza sentimentului
care îl inspir ă se vor realiza statisticii pentru acesta. Singurele persoane care sunt autorizate să acceseze
aceste statistici sunt acelea cu rol de administrator al aplicației.

Figura 4. 10. Pagina de statistici

Pe lângă faptul că poate vizualiza statisticiile, administrator ul poate exporta datele din diagrama de
statistică în format CSV, document care va fi transmis la firma care a lansat pe piaț ă produsul respectiv.

Figura 4.1 1. Exportul datelor din diagramele de statistici
Acesta pe lângă accesul la statistici mai are privilegiul de a manageria membrii aplicației, putând edita
sau șterge utilizatori.

47

Figura 4.1 2. Pagina de management a utilizatorilor
Astfel poate edita un utilizator care are un cont activ în aplicație, pe l ângă datele personale la care
membrii aplicației au acces atunci când se autentifică, administratorul aplica ției poate atribui și roluri,
astfel în funcție de rolurile asignate privilegiile utilizatorului cresc.

Figura 4.1 3. Editarea unui utilizator de către administratorul aplicației

48
Un utilizator f ără privilegiu de administrator are acces doar la datele lui personale, date care se găsesc
pe pagina de UserDetails unde dacă dorește poate adăuga/actualiza date despre el, acestea vor rămâne
pe pagină până la urm ătoarea modificarea din partea utilizatorului sau a administratorului.

Figura 4.1 4. Editarea datelor personale de către utilizatorul autentificat pe pagină
Pentru o comunicare cât mai facilă cu adminstratorul aplicației a fost implementat un chat care permite
comunicarea directă cu acesta atunci când este aut entificat. În figurile următoare va fi prezentată
această funcționalitate.

Figura 4.1 5. Contactarea administratorului prin chat -ul aplicației

Figura 4.1 6. Pagina de chat dedicată administratorului aplicației

49

Figura 4.1 7. Prezentarea modului în care vor fi afișate mesajele

50
5. Concluzii
Aceast ă lucrare are ca și scop prezentarea procesului de creare a unei aplica ții web complexe
folosind ca limbaj de programare .NET, framework -uri furnizate de acesta , principii și design pattern –
uri care ajut ă la proiectarea unei arhitecturi fiabile, u șor de men ținut și modificat.
Aplica ția abordeaz ă un target important pentru firmele producatoare de produse și consumatori . Și
anume s atisfac ția care o aduc utilizatorilor produsele cu care interac ționeaz ă. Astfel tot acest proces
este facilitat prin tr-o aplica ție web unde produsele sunt postate iar persoanele care le -au testat vor
adăuga review -uri care prin procesul de prelucrare a limbajului natural vor fi procesate iar pe baza
rezultatelor se vor realiza diagrame cu statistici a c ăror con ținut vor ajunge la firmele care produc
produsele respective.
Func ționalitatea proiectului este de 100% având func ționalit ățile implementate at ât pe partea de server
cât și pe partea de client . În lucrare am abordat at ât necesit ățile care au dus la apari ția și utilizarea unor
principii și tehnologii c ât și modul în care acestea au fost implementate în aplica ție. Pentru a realiza o
aplica ție web performant ă nu este suficient s ă ne limit ăm la faptul c ă funcționeaz ă, trebuie s ă găsim
mereu modul cel mai optim în care acele funcționalit ăți să fie implementat e. Acest domeniu este într-
o dezvoltare continu ă astfel pentru cele mai multe probleme s -au găsit deja solu ții, rămâne doar la
latitudinea programatorului dac ă dorește o aplica ție care doar funcționeaz ă sau dore ște o aplica ție care
să fie rapid ă, ușor de men ținut și dezvoltat. Am optat pentru a doua vari antă astfel pentru proiectare
am decis să urmez bunele practici pentru construirea unei aplicații complexe, am ales să fo losesc o
arhitectură N -Tier care presupune modularizarea aplicației. Pentru implementarea acestei arhitecturi
am urmat principiile S.O.L.I.D put ând să gestionez majoritatea prob lemelor de proiectare astfel am
putut trece de la un cod plin de dependințe și cu un grad de încapsulare mică la un cod decuplat și
încapsulat .
Pornind de la ideea de baz ă a aplica ției și anume sentimentul utilizatorului fa ță de produsul
testat și realizarea de statisticii pe baza acestuia, statistici care vor ajung e la firmele producatoare am
considerat c ă aplica ția are nevoie de o pagin ă de produse de unde utilizatorul s ă poată alege produsul
testat sau produsul care îl intereseaz ă să îl achizi ționeze. Pentru a ad ăuga review -uri avem nevoie de
un loc dedicat pentru aceast ă funcționalitate , având în vedere c ă este necesar ă o coresponden ță între
produs și review am ad ăugat aceast ă funcționalitate pe pagina produsului, astfel fiecare produs pe
lângă review -uri va avea detaliate și specificațiile tehnice , în acest mod utilizatorii vor putea face o
paralel ă între detali ile produsului și review -urile adăugate/ primite. Procesarea review -urilor este f ăcută
cu una dintre cele mai noi tehnologii de AI de la Azure și anume Text Analytics API care va procesa
conținutul textului furniz ând scoruri între zero și unu, unu fiind cel mai pozitiv , având parte astfel de
rezultate sigure și rapide . Pe baza acestor scoruri au fost stabilite reguli pentru diferite valori ale
acestora rezult ând astfel o clasificare a review -urilor în foarte bun, bun și nesatisf ăcător. Aceast ă
clasificare împreun ă cu num ărul de review -uri din fiecare categorie vor ajunge la diagramele de
statistici și apoi vor putea fi exportate în format C SV și transmise mai departe firmelor producatoare.
Pentru a putea ține o eviden ță a persoanelor care ad augă review -uri, adugarea de review -uri este
restric ționat ă, put ând ad ăuga doar persoanele care au deja un cont activ pe aplica ție și sunt
autentificate. Astfel exist ând aceast ă necesitate am implementat pagin ă pentru înregistrare și
autentificare. Utilizatorii care se înregistreaz ă se pot sim ți siguri în leg ătură cu protec ția datelor
deoarece aplica ția folose ște algoritmi complec și de cripta re astfel la înregistrare parola nu va fi salvat ă
în clar în baza de date ci va fi criptat ă înainte de ad ăugare, pentru autentificare aceast ă parol ă nu este
decriptat ă, întotdeauna c ând un utilizator se autentific ă parola acestuia va fi criptat ă și comparat ă cu

51
parola din baza de date a acelui utilizator , în cazul în care g ăsește o potrivire utilizatorul va primi acces
în aplica ție. Tot pentru securitate și o performan ță mai bun ă a aplica ției am implementat un sistem de
confirmare a înregistr ării pr in intermediul mail -ului, astfel pe aplica ție vor fi conturi active doar cele
care au fost confirmate de pe adresa de mail cu care s -a făcut înregistrarea. Pentru protec ția anumitor
date din aplica ție este necesar s ă restric ționăm accesul astfel am integra t sistemul de roluri prin care
creăm o ierarhie în aplica ție conferind astfel privilegii de accesare în func ție de rolul utilizatorului.
Spre exemplu conturile care au atribuit rolul de administrator al aplica ției vor putea avea acces la toate
statisticiile produselor, la datele utilizatorilor pe care le vor putea modifica sau șterge și deasemenea
vor putea oferii privilegiu de administrator sau alt rol utilizatorilor . Iar un utilizator care are cont pe
aplica ție și nici un alt rol suplimentar v a avea acces doar la datele lui personale.
Aplica ției îi pot fi aduse îmbun ătățiri astfel perspectivele de viitor ale acesteia ar fi urmatoarele:
• Înregistrarea și autentificarea s ă poată fi făcută cu aplica ții precum Facebook și Gmail
• Mesajele transmise pr in chat s ă fie păstrate dac ă administratorul nu este autentificat
• Calcularea unor note pentru produse pe baza review -urilor primite
• Îmbunătățirea funcționalităților existente
Iar ca perspectiv ă pe termen lung a ș dori ca chatul s ă fie implementat ca un bot de AI astfel pe baza
mesajelor primite chatul s ă furnizeze r ăspunsurile necesare.

52
6. Bibliografie
[1] E. Krivy,"Object -Oriented Simulation of systems with sophisticated control" , International Journal
of General Systems , pp. 313–343, 2011 [3.07.2018]
[2]https://encryptedtbn0.gstatic.com/images?q=tbn:ANd9GcTpXhwXChvvsERxU3M sORKrt3SV8J
mRLUivnkJ6wT2EDwpohr -HlQ [3.07.2018]
[3]https://yaplex.com/media/1012/dependencyinjection.png?anchor=center&mode=crop&width=350
&rnd=131423611390000000 [3.07.2018]
[4] http://www.entityframeworktutorial.net/images/EF5/persistance -fg1.PNG [3.07.2018]
[5] David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal, Sailu Redd y, HTTP: The Definitive
Guide , 1 edition ,O'Reilly Medi a, Oct. 7 2002 [3.07.2018]
https://www.amazon.ca/HTTP -Definitive -Guide -David -Gourley/dp/1565925092 [3.07.2018]
[6] http://wiki.hashphp.org/images/6/67/HTTP_Model.jpg [3.07.2018]
[7]https://lh3.googleusercontent.com/wr7NHsOaEHgeZZSNC2yvulXIj9b2CBoYW4QnjIEhbM Yqo
che-3t-qjv7QddVJBXEG_eBNg=s170 [3.07.2018]
[8],[9],[10],[11]https://azure.microsoft.com/en -us/services/cognitive -services/text -analytics/?v=18.05
[3.07.2018]
[12]https://encryptedtbn0.gstatic.com/images?q=tbn:ANd9GcTzfsiHBvUCmuYVYly3rsmGAPoHhu
7QP3TgO47ZwaTYceRrOX7k [3.07.2018]
[13] https://www.intertech.com/Blog/the -dependency -inversion -principle -with-c-examples/
[3.07.2018]
[14], [15], [16], [17], [18] Robert C. Martin ,S.O.L.I.D: The First 5 Principles of Object Oriented
Design, 2000
https://scotch.io/bar -talk/s -o-l-i-d-the-first-five-principles -of-object -oriented -design [3.07.2018]
[19] Leonard Richardson, Sam Ruby , RESTful Web Services by, O'Reilly Media , December 2008
http://shop.oreilly.com/product/9780596529260.do [3.07.2018]
[20] Robert C. Martin, Agile Principles, Patterns, and Practices in C# ,1st Edition , Prentice Hall , July
20, 2006 [3.07.2018]
[21] Robert C. Martin , Clean Architecture: A Craftsman's Guide to Software Structure and Design
(Robert C. Martin Series) 1st Edition , Prentice Hall,Sep 10 2017 [3.07.2018]
[22] Robert C. Martin , Clean Code: A Handbook of Agile Software Craftsmanship , 1st Edition ,
Prentice Hall , July 17, 2008 [3.07.2018]
[23] Dan Clark , Beginning C# Object -Oriented Programming (Expert's Voice in .NET) 2nd Edition ,
Apress, March 26, 2013 [3.07.2018]
[24] Access modifiers
https://docs.microsoft.com/en -us/dotnet/csharp/language -reference/keywords/access -modifiers
[3.07.2018]
[25] Joyce Farrell ,Microsoft Visual C#: An Introduction t o Object -Oriented Programming 7th Edition ,
Cengage Learning, July 13, 2017 [3.07.2018]
[26] Design Patterns in C# (Software Patterns (Paperback)) 1st Edition by Steven John Metsker
[27] Dependency Injection in .NET Sep 28, 2011 by Mark Seemann [3.07.2018]
[28] (2013) Dependency Injection with Unity
https://www.microsoft.com/en -in/download/details.aspx?id=39944 [3.07.2018]
[29] Tony Bevis ,C# Design Pattern Essentials , Ability First Limited , November 8, 2012
https://www.amazon.com/Design -Pattern -Essentials -Tony -Bevis/dp/0956575862 [3.07.2018]
[30] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides , Design Patterns: Elements of
Reusable Object -Oriented , Addison Wesley , Oct 31 1994 [3.07.2018]

53
[31] Julia Lerman , Programming Entity Framework , 1st Edition , O'Reilly Media, February 13, 2009
[3.07.2018]
[32] Julie Lerman , Entity Framework – Entity Framework 6: The Ninja Edition , MSDN , Decembrie
2013
https://msdn.microsoft.com/en -us/magazine/dn532202.aspx [3.07.2018]
[33] Jamie Kurtz, Brian Wortman , ASP.NET Web API 2: Building a REST Service from Start to
Finish , 2nd ed. E dition , Apress, July 28, 2014 [3.07.2018]
[34] Ross Mistry, Stacia Misner , Introducing Microsoft SQL Server 2014 , Microsoft , April 2, 2014
https://blogs.msdn.microsoft.com/microsoft_press/2014/04/02/free -ebook -introducing -microsoft -sql-
server -2014/ [3.07.2018]
[35] Steve Fenton , Pro TypeScript: Application -Scale JavaScript Development , 1st Edition , Apress ,
August 20, 2014 [3.07.2018]

54
7. Anexe
Anexa 1 . Exemple de cod pentru procesarea review -urilor extrase din implementare

● Adăugarea unui review de pe partea de front :

● Controllerul dedicat requesturilor legate de review -uri venite de la client pentru server sau invers

● Contractul aplicației cu serviciul de review

55

● Metoda de procesare a conținutului review -ului și determinarea sentimentului :

● Adăugăugarea unui review procesat în baza de date :

● DTO -ul review -ului prin care se face comunicarea dintre client și server :

● Enititatea corespunzătoare review -ului:

56

● Maparea dintr -un DTO într -o entitate :

● Review -uri existente în baza de date :

57

Anexa 2. Prezentarea relațiilor dintre tabelele bazei de date

58
Anexa 3
PERSONAL INFORMATION Iulia Rad
Nr.14,main Street,Fodora,Salaj,Romania,
0753591339
iulia_rad19@yahoo.com
WORK EXPERIENCE

https://github.com/IuliaRG/AdvanceSearchOfTechnologies
A site dedicated for the companies who have new produc ts on the market and
want to have a feedback from customers to make an idea of what they can
improve. The idea of this application is that people who try the products based
on their product experience gives a review and with text analysis we can tell if
the user was happy with this product or not and our customers will receive
statistics about their products For now the application has:login page, register
with email confirmation, change and reset password with email confirmation,
page with all the users th at can be edited or deleted of admin the page also has
pagination and a page where the admin can edit a user,a chat where you can talk
with the admin of the page,a page for statistics where are displayed charts and
also the page with all the products

Technologies used:
▪ASP.NET Web API
▪Entity Framework
▪ HTML,HTML5 ,CSS
▪Angular JS
▪JavaScript

https://github.com/IuliaRG/SharePointWorkflow

59
Internship on Digital Workplace where I worked with SharePoint. The idea of
application was a software solution for helping service desk operators classify
and resolve tickets with the use of artificial intelligence.
Front office will input content from e -mails into a SharePoint list, containing the
fields: From, Subject, Body. Based on the subject and body, we used Microsoft’s
Text Analytics API to identify the keywords mentioned in the e -mail and route it
to the appropriate team:
– Errors: should go into a technical backlog (another
list in SharePoint) – Requests for information: should
get to the marketing team And there we had some
things to do for every ticket.
The total number of tickets, as well as how they are progressing were shown in
graphs that highlight ticket status .

Technologies used:
▪SharePoint
▪ HTML
▪JavaScript
▪Bootstrap

Iulia Rad
https://github.com/tecknoworks/FlyVideos/tree/master/FlyVideosWeb/Scripts/a
pp
During two months I did an internship focused on the front end development
.The application consists from a store where customers can buy or rent drones or
drone accessories. It has pagination, search box and other filters that can be used
to find the desired items. Before a customer can place an order, he must create
an account with minimum shipping details. The registration mechanism supports
local accounts bu t also Facebook authentication. The customer can update his
information at any time from a specific user profile that also contains the order
history. All the items the customer wants to acquire are placed into a shopping

60
cart that has a specific page wher e the item quantities can be edited and final
price is automatically calculated. From the cart an order can be placed where the
user can review again all the details. The payment is exclusively online and done
using credit card.

Technologies used:
▪ HTML ,HTML5 ,CSS
▪Angular JS
▪JavaScript
▪AJAX
▪Bootstrap

An application for android which deals with the management of lost and found
objects the application has a page for lost/found items,a filter who display items
by category, register and login page, p age where you can add lost or found
objects with specific details,a user profile page and a page where you can contact
the admin of the application.

Technologies used: ▪ Android Studio

And a kind of internship related of Development of graphic element s and their
use in digital publications offered by Center of Research Multimedia and
Telecommunications.
EDUCATION AND TRAINING
15/09/2010 –
22/06/2014 Mathematics and Computer Science
"Alexandru Papiu Ilarian" High School Lupeni 2, 405200 Dej (Romania)
01/10/2014 –
Present Faculty of Electronics, Telecommunications and the Technology of Information
Technical University, Cluj -Napoca (Romania)
http://etti.utcluj.ro/
PERSONAL SKILLS

Mother
tongue(s) Romanian

61
Foreign
language(s)
English
French
Levels: A1 and A2: Basic user – B1 and B2: Independent user – C1 and C2: Proficient user Common
European Framework of Reference for Languages
Communication
skills Good communication skills gained from various volunteer activities organized by
Students Organization of Technical University
Organisational / managerial
skills Teamwork skills gained through teamwork projects from University and
internship, ability to work
Iulia Rad
under pressure. I'm an ambitious person and always open to new experiences.
Job-related skills Programming skills :
▪ C/C++
▪Object -oriented programming
▪Java
▪ HTML,HTML5 ,CSS
▪AJAX
▪AngularJS
▪JavaScript
▪jQuery

UNDERSTANDING
SPEAKING
WRITING
Listening
Reading
Spoken interaction
Spoken production
B2
B2
B2
B2
B1
A2
A2
A1
A2
A2

62

Anexa 4. Test detecție plagiat