Proiect Licenta Acs Tudor G A Bogdan Paul 87823 [631901]

Universitatea POLITEHNICA Bucure ști
Facultatea Automatică și Calculatoare
Departamentul Automatică și Informatică Industrială

LUCRARE DE LICENȚĂ

Aplic ație de socializare pentru arti ști

Coordonator Absolvent
S.l. dr. ing. Oana Chenaru Bogdan -Paul Tudor

Anul absolvirii 2019

2

Sinopsis

Rețelele de socializare se bucură de o foarte mare popularitate în zil ele noastre, în
special în rândul tinerilor. Totodată putem spune că există o înclinație către partea artistică
atât în rândul consumatorilor cât și și în rândul creatorilor de conținut. Având aceste lucruri
în minte această lucrare propune o soluție softw are pentru a ușura interacțiunea dintre
artiștii actuali ai domeniului muzical și aspiranții către aceasta profesie, o aplicație web
numita VAL (Various Artists Linked). Această lucrare va prezenta modul de creare al
acestei platforme web într -un mod detal iat, precum și modul de utilizare al acesteia. În
final vor fi oferite și o serie de idei pentru dezvoltări ulterioare.

3

Cuprins

Lista de figuri ………………………….. ………………………….. ………………………….. ………………… 5
Lista de acronime ………………………….. ………………………….. ………………………….. …………… 7
1. Introducere. Scurtă istorie a rețelelor de socializare ………………………….. ………….. 9
2. Scop și motivare ………………………….. ………………………….. ………………………….. 11
3. Arhitectura aplicației ………………………….. ………………………….. …………………….. 13
3.1. Arhitectura sistemului de gestiune al bazei de date ………………………….. …………. 15
3.1.1. User ………………………….. ………………………….. ………………………….. ………………. 16
3.1.2. Prietenii ………………………….. ………………………….. ………………………….. …………. 18
3.1.3. Postări ………………………….. ………………………….. ………………………….. ……………. 19
3.1.4. Mesaje ………………………….. ………………………….. ………………………….. …………… 20
3.2. Accesul la baza de date prin Entity Framework Core ………………………….. ……… 22
3.3. Servicii și logica de business ………………………….. ………………………….. ………….. 26
3.4. Interfața grafică cu utilizatorul ………………………….. ………………………….. ……….. 27
3.4.1. Componenta Model ………………………….. ………………………….. ………………………. 28
3.4.2. Componenta Control ler ………………………….. ………………………….. …………………. 28
3.4.3. Componenta View ………………………….. ………………………….. ……………………….. 31
3.4.4. JavaScript ………………………….. ………………………….. ………………………….. ………. 32
3.4.5. Bootstrap ………………………….. ………………………….. ………………………….. ……….. 33
4. Utilizarea Aplicației ………………………….. ………………………….. ……………………… 37
5. Concluzii și dezvoltări ulterioare ………………………….. ………………………….. …….. 45
6. Bibliografie ………………………….. ………………………….. ………………………….. …….. 47

4

5 Lista de f iguri

Fig1. Numărul personalor ce folosesc cel puțin o rețea de socializare și creșterea acestora
estima
Fig 2. Graficul creșterii persoanelor a ngajate în industria muzicală
Fig3. Arhitectura UML a aplicației
Fig.4. Diagrama bazei de date
Fig.5. Tabel a User
Fig.6. Relațiile dintre utilizator, genuri muzicale și aptitudini
Fig.6.1.Relația dintre utiliziator și prieteni și utilizator și cereri de prietenie
Fig.7. Relația dintre uitilizatori, postări și comentarii
Fig.8. Relația dintre tabela utilizatori și mesaje
Fig.9 .Codul C# care va fi tradus în instrucțiuni SQL pentru tabela dbo.Users
Fig. 10. Schema de design pent ru Unit Of Work și Repository
Fig. 11.Clasa BaseRepository cu metodele CRUD
Fig. 12.Clasa ValUnitOfWork care inițializează componentele d e tip Repository
Fig. 13.UserAccountService
Fig.14.REST in ASP.NET
Fig.15.Metodele de GET și POST pentru crearea unui cont nou în VAL
Fig.16 .Clasa ProfileController și dependințele acesteia.
Fig.17.Implementarea componentei View de tip CSHTML pentru adăug area de postări/
evenimente
Fig.18. Segment de cod JavaScript pentru trimiterea pe server a formularului de scriere de
evenimente
Fig. 19. Creșterea în popularite Bootstrap de -alungul anilor
Fig. 20. Cele mai utilizate frame work -uri în aplicațiile web
Fig. 21. Pagina de autentificare în aplicație
Fig. 22. Pagina de înregistrare în aplicație
Fig.23. Pagina de Home a aplicației
Fig.24. Pagina de editat profilul aplicației
Fig.25. Pagina de gestionare a prieteniilor
Fig. 26. Pagina de gestionare a cererilor de prietenie
Figura 27. Pagina de gestionare a evenimentelor
Fig.28. Funcționalitatea de a căuta în aplicație utilizatori
Fig.29. Pagina de vizualizare a profilurilor
Fig. 30. Pagina de gestionare a mesajelor

6

7 Lista de acronime

API – Application Programming Interface
AJAX – Asynchronous JavaScipt And XML
ASP – Active Server Page
CSHTML – C# HTML
CSS – Cascading Style Sheets
Dbo – Database object
DOM – Document Object Model
HTML – Hypertext Markup Language
HTTP – Hypertext Transfer Protocol
HTT PS – HyperText Transfer Protocol Secured
JSON – JavaScript Object Notation
MVC – Model View Controller
ORM – Object Relation Mapper
REST – Representational State Transfer
SGBD – Sistemul de gestiune al bazei de date
SQL – Structured Query Language
UML – Unified Modeling Language
URI – Uniform Resource Identifier
URL – Uniform Resource Locator
VAL – Various Artists Linked
XML – Extended Markup Language

8

9
1. Introducere. Scurtă istorie a rețelelor de
socializare

O rețea de socializare este o aplicație web menită să faciliteze interacțiunea dintre
persoane, indiferent de distanța, contextul sociocultural din care aceștia provin. Am putea
spune chiar că rolul acestora este de a depăși barierele de comunicare de diverse feluri.
O formă primitivă a rețelel or de socializare a fost reprezentată de apariția
bloggurilor. Acestea au apărut în perioada anilor 1994 -1996. Primul blog lansat pe internet
îi aparține lui Justin Hall, jurnalist din Statele Unite ale Americii. [1]
Ceea ce făcea bloggurile atrăgătoare er a faptul că o mai mulți oameni își puteau
împărtăși în mediul online gândurile/părerile/convingerile și totodată alți utilizatori puteau
comenta postarea în cauză.
Mai târziu în 1997 a apărut prima rețea de socializare, Six Degrees , care a durat
până în 2 001. Numele acesteia este inspirat din teoria celor șase grade de separare, teorie
care susține faptul că între oricare doi oameni din lume există maximum șase grade de
separare. [15] Ce a făcut Six Degrees să fie considerată revoluționară în acest domeniu este
că această aplicație oferea posibilitatea utilizatorului de a -și personaliza profilul și totodată
de a-și selecta cercul de prieteni virtuali. [2].
În perioada anilor 2000 au existat mai multe rețele de socializare care n -au rezistat
testului timpului , însă două s -au remarcat : Facebook si LinkedIn .
În ceea ce privește Facebook , aceasta a apărut în 2004, cu numele original The
Facebook și a fost concepută ca rețea de socializare pentru studenții de la Harvart. Scopul
acesteia era comunicarea facilă în c adrul studenților facultății. Aplicația a avut un impact
major, a câștigat foarte mare popularitate și foarte rapid în rândul studenților de la Harvart
și datorită lor aceasta s -a extins foarte mult. Câțiva ani mai tarziu, The facebook își
schimbă numele î n Facebook și totodată își modifică publicul țintă din studenți în întreaga
populație. [3]
LinkedIn a pornit din 2003 și nu a avut un start remarcabil (doar 20 de abonați în
prima luna). Aplicația de socializare având ca public țintă antreprenorii și reprez entanții
forței de muncă a câștigat popularitate abia în 2006, după ce au fost adăugate mai multe
funcționalități de către echipa de dezvoltare. [4] Spre deosebire de Facebook , după ce
LinkedIn a căpătat popularitate aceștia și -au menținut publicul țintă și au continuat să
aducă îmbunătățiri aplicației.
În prezent rețelele de socializare au devenit o afacere profitabilă și prosperă,
Facebook având cifra de afaceri de aproximativ 138.3 miliarde de dolari americani în 2018
[5], iar LinkedIn cu cifra de aface ri de 27 de miliarde de dolari americani când a fost
achiziționat ă de către Microsoft în 2017.[6]

10

11
2. Scop și motivare

Așa cum am menționat și în capitolul anterior rețelele de socializare reprezintă
afaceri prospere și cu posibilitate de dezvoltare co nsiderabilă, care s -au păstrat pe un trend
ascendent, estimându -se ca în anul 2021 numărul utilizatorilor va ajunge la peste 3
miliarde. [7]

Fig1. Numărul personalor ce folosesc cel puțin o rețea de socializare și creșterea acestora estimată [7].

Un alt motiv care justifică rețeaua de socializare propusă de această teză este faptul
că domeniul muzical se bucură de o dezvoltare consistentă, mai precis numărul persoanelor
angajate în industria muzicală a crescut de peste patru ori din 2005, de la apariția
platformelor online Facebook și Apple Store , chiar mai mult, în Statele Unite se remarcă
faptul că meseria de compo zitor muzical este a treia meserie ca creștere a numarului de
angajați [8].

12

Fig 2. Graficul creșterii persoanelor angajate în industria muzi cală[8]

Ținând cont că rețeaua de socilizare propusă de această lucrare de licență se adresează
grupul socioeconomic al artiștilor din industria muzicală, am luat modelul aplicației
LinkedIn , platformă care se concentrează asupra distribuirii forței de m uncă, și am creat
propriul model de aplicație de socializare nișată pe acest grup.

13 3. Arhitectura aplicației

În acest capitol vom discuta despre arhitectura și tehnologiile folosite pentru
construcția aplicației web. Aplicația a fost construită d upă următorul model
arhitectural:

Fig3. Arhitectura UML a aplicației

Acest model arhitectural oferă o serie de avantaje, în primul rând organizarea în trei
straturi permite diverse îmbunătățiri, fără a modifca segmente de cod existent , se pot
execut a în paralel aplicații pe mai multe platforme folosind aceleași resurse, dar
totodată, această arhitectură de separare a entităților de server creează constângeri
asupra utilizatorului pentru ca acesta să nu poată accesa niciodata direct baza de date.
Așad ar, nivelul de abstractizare reprezentat de Logica de Business si Accesul la Baza
de Date sunt un prag de securitate în plus pentru posibilii utilizatori rău intenționați.
După cum se poate observa fun cționalitatea aplicației este impărțită în trei stratur i
de jos în sus după cum urmează:

14 a. Arhitectura sistemul de gestiune al bazei de date
b. Logica de business și algoritmica aplicației
c. Interfața grafică cu utilizatorul

15
3.1. Arhitectura sistemului de gestiune al
bazei de date

Pentru a facilita buna înțelegere a relațiilor dintre tabelele bazei de date vom
folosi următoarea diagram ă a bazei de date:

Fig.4. Diagrama bazei de date

În următoarele subcapitole vom defini fiecare tabelă și vom descrie rolul acestora în
gestiunea datelor din aplicație.

16 3.1.1. User

Tabe la User (utilizator) este cea mai importantă tabela din baza de date întrucât
aceasta conține cele mai multe informații și are cele mai multe legături. Deoarece am
dezvoltat o aplicație de socializare, accentul este pus asupra utilizatorului și experienței
sale.

Fig.5. Tabela User

Avem următoarele câmpuri:
– ID, cheie primară cu rol de identificator, constrângere de autoincrementare și cu
index primar
– Email și Parola (Password), câmpurile cu care utilizatorul se autentifică în
aplicație. De asemenea câmp ul email are constrângere de unicitate
– Firstname, Lastname, GenderType (Nume, Prenume, Sex), câmpurile pe care
o persoana le completează la pasul de autentificare în aplicație

17 – IsBand (EsteFormație), Bandname, VAL este o aplicație care accepta două
tipuri d e utilizatori: atât persoane fizice cât și formații/trupe. Folosim IsBand,
identificator de tip boolean, la înregistrarea în aplicație pentru a crea contul
pentru o formație de muzică
– Bio, câmp opțional, reprezintă o scurtă descriere a unui indiv sau a une i
formații despre sine însuși
– CityId, ProfilePhotoId, chei străine tabelelor Locație și Media pentru a
completa câmpurile opționale cu scopul de a oferi mai multe informații despre
un utilizator
Pe lângă câmpurile care trebuiesc completate la înregistrare, un utilizator are
opțiunea de a -și particulariza profilul și mai mult, în funcție de genurile muzicale preferate,
la care este activ, și de talentele acestuia în domeniu. Avem urmatoarele tabele: dbo.Skills (
Aptitudini ) și dbo.Genres ( Genuri muzicale ) . Legăturile acestor tabele cu tabela
principală a utilizatorului sunt de tipul NxN, deci prin urmare vom folosi două tabele
intermediare dbo.UserSkills alături de dbo.UserGenres .

Fig.6. Relațiile dintre utilizator, genuri muzicale și aptitudini

18

3.1.2. Prietenii

Fig.6.1.Relația dintre util iziator și prieteni și utilizator și cereri de prietenie

Scopul aplicației de socializare este de a crea cât mai multe conexiuni între
utilizatori, astfel utilizatorii pot comunica într -un mod facil direct sau in direct în cercul lor
social. Și în acest sens baza de date ține informațiile legate de prieteniile actuale ale unui
utilizator atât și informațiile despre viitoare posibile prieteii dintre utilizatori.
Implicit un utilizator la crearea contului nu va avea niciun alt utilizator în cercul său
de prieteni. Acesta va căuta alți utilizatori din baza de date prin interfaț a grafică și le va
solicita prietenia, în acel moment tabela dbo.FriendRequests va salva cererea și dacă
ulterior persoana/formația solicitată v a acepta cererea atunci înregistrarea din
dbo.FriendRequests va fi ștearsă și se va adăuga o înregistrare similară în tabela
dbo.Friends , marcând începutul prieteniei virtuale.

19

3.1.3. Postări

Fiecare utilizator are posibilitatea de a -și exprima gândurile oricând pe rețeaua de
socializare, chiar mai mult, un utilizator poate organiza și evenimente, ambele entități sunt
gestionate de tabela dbo.Posts și în plus, utilizatorii iși pot împărtași direct opinia prin
comentarii la postări/evenimente. Diferențele d intre postări și evenimente se fac în primul
rând la nivel logic prin câmpul de tip boolean IsEvent și în al doilea rând prin
funcționalitățile diferite ale evenimentelor. Spre deosebire de o discuție, un eveniment
prezintă și două date calendaristice, una ce marchează începutul evenimentului și alta ce
marchează sfârșitul acestuia, un nume, o descriere și posibilitatea utilizatorului de a -și
exprima opțiunea de a participa sau nu la evenimentul în cauză.
Relația diintre utilizatori, postări/evenimente și comentarii este ilustrată în figura
urmatoare:

20

Fig.7. Relația dintre uitilizatori, postări și comentarii

3.1.4. Mesaje

O altă funcționalitate a aplicației este aceea de a gestiona mesajele transmise de la
un utilizator la altul. Mesajele sunt stocate în ta bela dbo.Messages . Tabelă cu cheie străină
compusă SenderId ( emițător ) către tabela dbo.Users , și ReceiverId ( receptor ) de
asemenea către tabela dbo.Users.
Diagrama tabelelor de stocare a mesajelor din cadrul aplicației este următoarea:

21

Fig.8. Relați a dintre tabela utilizatori și mesaje

22 3.2. Accesul la baza de date prin Entity
Framework Core

Entity Framework Core este un O/RM ( Object -Relational Mapper ) din librăria
Microsoft folosit pentru a „traduce” obiectele din limbaj SQL în clase C#. În cadrul
proiectului de DataAccess am folosit design pattern -urile (eng. design pattern = tehnica de
programare) Unit of Work și Repository.

Fig.9 .Codul C# care va fi tradus în instrucțiuni SQL pentru tabela dbo.Users

23

Fig. 10. Schema de design pentru Unit Of Work și Repository [9]

Design Pattern -ul Repository este folosit pentru a abstractiza un strat între clasele
traduse cu Entity Framework Core și logica de business. Ideea din spatele metodei
Repo sitory este că fiecare entitate va implementa interfața IRep ository , indirect prin
interfața IEntity , cu metodele de acces la baza de date: Add(), AddRange(), Remove(),
RemoveRange(), Update() .
Aceste metode sunt interne bibliotecii Entity Framework Core și vor fi traduse în cod SQL,
cod corespunzator operațiilor d e adăugare, modificare și ștergere din baza de date.

24

Fig. 11.Clasa BaseRepository cu metodele CRUD

Design Pattern -ul Unit of Work functionează ca un depozit pentru toate enitățile ce
implementează IRepository (eng. repository = depozit), deci putem spun e că Unit of Work
este un Repository de Repositories (depozit de depozite). Ideea din spatele arhitecturii Unit
of Work este de a centraliza entitățile sub un context comun al bazei de date. Entity
Framework va genera clasele din obiecte SQL în obiecte C# și totodată va genera si
contextul bazei de date. Folosind Unit of Work vom aduce fiecare enitate să proceseze sau
să citească date din aceeași instanță a Contextului fără a fi nevoie să reinițializăm obiectul
de tip DbContext, ceea ce ar putea duce la de sincronizări ale datelor din baza de date.
Ca implementare Unit of Work va avea trei fișiere: interfața IUnitOfWork cu o
singură metodă – SaveChanges() și două clase – BaseUnitOfWork și ValUnitOfWork. În
ValUnitOfWork se va inițializa Contextul bazei de da te și fiecare repository aferent fiecărei
entități.

25

Fig. 12.Clasa ValUnitOfWork care inițializează componentele de tip Repository

26 3.3. Servicii și logica de business

Următorul strat după cel reprezentat de accesul la date este cel al logicii de
business. Logica de business reprezintă o serie de metode folosite pentru a realiza cerințele
de proiect. Fiecare entitate/repository va avea o clasa de servicii. Serviciile se vor folosi de
clasa UnitOfWork pentru a întoarce rezultatele din bază conform specificaț iilor.
De exemplu, User , entitatea cu complexitatea cea mai mare din aplicație, va avea
două clase de servicii: UserAccountService și UserProfileService. Pentru
UserAccountService vom implementa logica necesară autentificării și înregistrării. Vom
salva î n baza de date utilizatorul nou înregistrat, vom verifica să nu existe adrese de mail
duplicate, și vom întoarce utilizatorul în caz că credențialele sale sunt valide pentru a -l loga
în aplicație.

Fig. 13.UserAccountService

Fiecare clasă responsabil ă de executarea serviciilor va moșteni clasa BaseService ,
clasă unde inițializăm obiectul de tip ValUnitOfWork .

27

3.4. Interfața grafică cu utilizatorul

Interfața grafică este stratul prin care clientul comunică direct cu serverul printr -un
mediu ușor de uti lizat și intuitiv. Arhitectura interfeței respectă regulile din ASP.NET Core
de MVC ( Model – View – Controller ).
ASP.NET Core este o bibliotecă Microsoft care permite dezvoltarea aplicațiilor
web întrucât conține o serie de metode care faciliteaza trans ferul obiectelor prin
protocoalele HTTP, respectiv HTTPS folosind design pattern -ul REST.
Conceptul REST ( REpresentational State Transfer) a fost implementat de către
Roy Fielding și este menit sa evoce o imagine a cum ar funcționa o aplicație web cu o
arhitectură bine pusă la punct : o rețea de pagini web ( o mașină de stări virtuală ) … unde
utilizatorul navighează prin aplicație folosind link -uri ( stări tranzitive ) … resultând în
accesarea paginii următoare ( reprezentată de următoarea stare a ap licației ) fiind
transferată către utilizator și afișată pentru a putea fi utilizată.
Bilbioteca ASP.Net Core are implementat design -ul de REST și acesta facilitează
transferul de date de la client la server și vice versa prin convertirea obiectelor de tip C#
(Server) în obiecte JSON (Client) și vice versa.

Fig.14.REST in ASP.NET [14]

28

3.4.1. Componenta Model

Componenta model reprezintă un obiect cu rolul de legătură între entități și obiecte
de tip JSON ce ajung să fie afișate pe client.
De exemplu pentru entitatea de Utilizator vom avea două obiecte de tip Model:
UserVm și UserProfileVm. Întrucât utilizatorul este nucleul aplicației, acesta va fi afișat
într-o formă sau alta pe client, astfel încât noi vom transfera numai datele de care avem
nevoie. Pentr u modelul UserVm vom păstra numai ID -ul, Numele, Prenumele și poza de
profil deoarece interacțiunea indirectă cu alți utilizatori ( afișarea lor prin postări,
evenimente sau cereri de prietenie ) este minimalistă. În cazul lui UserProfileVm dorim să
transmitem cât mai multe date întrucât acesta este transmis pe client pe paginile
responsabile de vizualizare sau editare de profil. Aceste URI -uri ( Unified Resource
Identifier) conțin informații integrale referitoare la utilizatorul în cauză.

3.4.2. Componenta Controller

Componenta Controller reprezintă, asemeni compo nentei Model, o legătură, însă de
această dată Controller -ul are rolul de a transfera datele în și dinspre server la client. Un
controller este un obiect de tip C# care definește m etode de tip IActionResult.
IActionResult este un tip de date aparținând blibliotecii ASP.NET Core integrată cu
protocoalele HTTP și HTTPS care transferă asincron datele folosind arhitectura REST.
IActionResult întoarce un cod HTTP pe care serverul îl va g estiona conform implementării.

29

Fig.15.Metodele de GET și POST pentru crearea unui cont nou în VAL

În figura de mai sus vedem o implementare pentru acțiunile de înregistrare, partea
de acces a paginii de înregistrare se va face folosind protocolul Http GET, pentru afișarea
conținutului paginii de înregistrare, iar trimiterea formularului de înregistrare se va face
folosind protocolul HTTP POST , și controller -ul va primii datele, le va converti din
modelul RegisterVm în User , și va parcurge tot drumul pri n straturile enunțate anterior
pentru a scrie în baza de date noul utilizator.
Componenta Controller se folosește de serviciile enunțate anterior pentru a citi date
din baza de date și a le trimite pe client, sau se pentru a primi date de la client și a l e
prelucra pe server. Modul prin care Controller -ul folosește Serviciile este prin tehnica de
programare numită Dependency Injection (eng. Injectarea dependințelor), acest deisgn
pattern presupune ca fiecare obiect ce participă la funcționarea aplicației s ă fie dependent
într-o anumita măsură de alt obiect mai sus în ierarhie. Aplicațiile construite cu ASP.NET
Core 2 vin implicit cu două clase Program.cs și Startup.cs . Rolul lui Startup.cs este acela
de a inițializa fiecare serviciu care va fi folosit în ap licație, în cazul de față avem diverse
servicii, cum ar fi: serviciul de autentificare, serviciul de rutare, serviciul de context al
bazei de date și, bineînțeles, serviciile din logica de business. Pentru a ușura scrierea
fiecare serviciu este inițializat într-o clasă de metode extise,
ConfigurationExtensionMethods.cs , și injectată în Startup.cs . Aplicația rulează folosind ca
fișier executabil Program.cs , acolo unde se invocă clasa de startup.

30 După cum spuneam mai sus, în Controller, serviciile sunt trans mise prin tehnica de
Depenndency injection, adică, în clasa specifică fiecărui controller vom declara serviciile
pe care le vom folosi, și în constructorul fiecărui Controller vom atribui datele transmise
prin Startup.cs acestuia.

Fig.16 .Clasa Profile Controller și dependințele acesteia.

Se poate vedea în figura de mai sus că serviciile sunt folosite așa cum au fost
descrise, aceasta tehnică este foarte „curată” întrucât nu există riscuri de desincronizări și
depanarea eventualelor erori este foarte uș oară, neconsumând mult timp.

31 3.4.3. Componenta View

View din limba engle ză înseamnă vedere în limba română, intuitiv vederea se ocupă
exclusiv de componentele care vor fi afișate, partea grafică din tot mecanismul MVC din
proiectul aplicației web.
ASP.NET Cor e vine cu o tehnologie proprie Microsoft numită RazorView ( eng.
Razor = aparat de ras/ lamă ) care îmbină dinamicitatea limbajului de programare C# cu
textul de marcaj pentru browserele web HTML. Fișierele RazorView au extensia cshtml,
efectiv C# HTML, ș i unicitatea lor vine din felul în care funcționează. Înainte de a afișa
conținutul unei pagini web, serverul va compila fișierele de tip cshtml în fișiere HTML și le
va trimite browserului, creând astfel programabilitate și flexibilitate fișierelor HTML.

Fig.17.Implementarea componentei View de tip CSHTML pentru adăugarea de postări/ evenimente

Se observă mai multe elemente în figura de mai sus. Odata putem vedea chiar pe
primul rând @model EventWithMediaVm , asta înseamna că obiectul de tip View așt eaptă
de la server să primească o Componentă model de tip EventWithMediaVm , pe care o va
prelucra mai departe prin obiectul intern Model.
De asemenea, se poate vedea că secvențele de cod C# sunt scrise între paranteze
acolade marcate cu @, în vedereile di n ASP.NET, caracterul @ este folosit pentru a marca
începutul limbajului de programare . Numele variabilelor, instrucțiunile și bucățile de cod
sunt marcate conform a ce a mai sus.

32 Deși componentele RazorView sunt foarte eficiente din punct de vedere
progr amatic, însă acestea nu răspund la client, fiecare acțiune a clientului va trebui să
reîncarce conținutul paginii, acest lucru fiind dificil în cazul aglomerării de elemente pe
server de tip Media/Multimedia, și bineînțeles în cazul conexiunilor lente la i nternet, deci
inevitabil se va crea o experie nță neplăcută pentru utilizator . De aceea aplicația web este
încărcată cu alte tehnologii web pentru manipularea DOM -ului ( Document Object
Model), adică JavaScript.

3.4.4. JavaScript

Conform autorilor, JavaScrip t este un limbaj de programare interpretat, orientat pe
obiecte făcut pentru browsere, acesta este foarte versatil și are capacitatea de a manipula
elementele din DOM în timp real, fără a fi nevoie de o încărcare totală a paginii.
Fiind o tehnologie cu is torie, acesta a devenit un standard pentru browserele web și
dezvoltatorii limbajului și -au permis sa creeze mai multe bilbioteci ajutătoare pentru
programatorii web. Bilbioteca folosită în aplicația VAL este jQuery.
jQuery este o biblioteca relativ mică pentru a ușura sintaxa JavaScript. Aceasta are
centralizată o variabila numita jQuery , însă pentru manipularea ușoară i s -a dat un alias – $.

Fig.18. Segment de cod JavaScript pentru trimiterea pe server a formularului de scriere de
evenimente

Pe lâng ă funcționalitățile care ușurează experiența JavaScript, jQuery aduce și o
metodă proprie, numită AJAX ( Asynchronous Javascript And Xml ), metodă care, așa cum

33 îi spune și numele, transferă obiecte de tip JSON sau XML înspre sau dinspre server spre
client . Este o unealtă foarte utilă pentru transferul de date parțiale ce nu necesită
reîncărcarea DOM -ului, de exemplu participarea la un eveniment, sau acceptarea unei
cereri de prietenie. [10]

3.4.5. Bootstrap

Cât despre partea de design al aplicației am ales să folosesc Bootstrap, un
framework CSS.
Boostrap este una dintre cele mai cunoscute framework -uri open -source de stil, și
totodată cel mai popular. A apărut în 2011 inițial ca o simplă bibliotecă de CSS sub numele
de Twitter Blueprint (biblioteca oficial ă internă a site -ului de socializare Twitter).
Deși inițial gândită ca ustensilă internă, dezvoltatorul principal al conceptului,
Mark Otto s -a gândit că, în profida contextului din 2011 în care site -urile mereu proneau de
la zero pentru a -și forma design -ul propriu, sau foloseau biblioteci interne, ar fi o idee bună
să publice ca open source Twitter Blueprint sub numele de Bootstrap pentru o fluidizare și
o standardizare a modului de dezvoltare al interfețelor grafice pe browser. Ideea a fost
repede îmbră țișată, mai ales de dezvoltatorii care iși porneau propriile afaceri și biblioteca
de atunci le -a accelerat procesul de design. [11]
Multe contribuții au fost aduse de -alungul timpului astfel că în 2018, acesta a
devenit cel mai popular framework de desig n. [12]

34

Fig. 19. Creșterea în popularite Bootstrap de -alungul anilor [12]

Fig. 20 . Cele mai utilizate framework -uri în aplicațiile web [12]

35 Un motiv pentru care Bootstrap a devenit foarte popular este și datorită
compatibilității dintre platforme. Aici intervine elementul de Bootstrap.js. Instalarea
Bootstrap din versiunea 3 vine la pachet opțional cu fișiere de javascript, aceste scripturi
fac o redimensionare automată a elementelor de bootstrap astfel încât portarea de la un
device de o anumită re zoluție (de exemplu un PC de 2140×1820) la un alt device de altă
rezoluție (de exemplu un laptop de 1080×720) să se facă automat și natural, astfel încât
elementele de design să nu fie date peste cap. Totodată, framework -ul este compatibil cu
majoritatea b rowserlor web ( Google Chrome, Mozilla Firefox, Internet Explorer,
Microsoft Edge, Opera, Safari șamd).

36

37 4. Utilizarea Aplicației

În acest capitol vom face o demonstrație a modului de funcționare al aplicației,
ilustrând prin capturi de ecran mai multe ca zuri de folosire.
Primul eveniment care are loc când un utilizator accesează pagina este
redirecționarea acestuia pe meniul de autentificare. Utilizatorul are opțiunea să se
autentifice în aplicație sau să își creeze cont în caz că acesta nu dispune de cre dențiale .

Fig. 21. Pagina de autentificare în aplicație

Fig. 22. Pagina de înregistrare în aplicație

38 Odată ce un utilizator s -a autentificat cu succes în site, acesta va observa un meniu
de navigare în stânga, alături de o bară de navigare la marginea de sus a paginii. Ruta pe
care va fi direcționat utilizatorul este Home/Index, acolo controller -ul îi va aduce
utilizatorului datele despre postările și evenimentele ce au fost scrise de către el sau de
prietenii acestuia.

Fig.23. Pagina de Home a apl icației

Pe lângă cele menționate anterior putem observa în meniul din stânga că butonul
corespunzător paginii în care ne aflăm este deosebit față de celelalte, totul cu scopul
îmbunatățirii experienței utilizatorului.
Clientul are opțiunea din ecranul p rincipal să scrie o postare sau chiar să organizeze
un eveniment. Fiecare entitate de tip post care se va încărca în broser, va fi văzută implicit
de cerul de prieteni al acestuia, sau de orice alt utilizator ce va căuta profilul clientului în
cauză. De as emenea la orice postare / eveniment, utilizatorul curent are opțiunea să încarce
fișiere media de tip imagini, și atât acesta cât și orice alt utilizator au permisiunea de a
adăuga comentarii la postări/evenimente.
Totodată, selectând avatarul din bara de meniu din stânga, un utilizator poate să iși
personalizeze fotografia de profil.
Urmatoarea opțiune din meniu este Edit Profile . Utilizatorul curent va fi
redirecționat către pagina de editat profil și va putea completa în formular diverse
informații, c onform figurii, care vor fi afișate public celorlalți clienți ai aplicației.

39

Fig.24. Pagina de editat profilul aplicației

Următoarele tab -uri din porțiunea de meniu sunt cele de Friends ( eng. prieteni ) și
de Friend Requests ( eng. cereri de prietenie ). Numele sunt foarte intuitive, utilizatorul este
redirecționat către URL -ul aferente gestionării prietenilor și cererilor de prietenie. În
imaginile de mai jos vom observa rolul și funcționalitatea acestora.

Fig.25 . Pagina de gestionare a prieteniil or

40

Fig. 26. Pagina de gestionare a cererilor de prietenie

Ultimul tab din secțiunea de meniu din aplicație este cel de evenimente ( Events ).
Acest buton redirecționează utilizatorul către pagina de gestionare a evenimentelor.
Utilizatorul are posi bilitatea de a vizualiza evenimentele care o să aibă loc și totodată iși
poate exprima opțiunea în ceea ce privește participarea sa la evenimentul respectiv.

41 Figura 27. Pagina de gestionare a evenimentelor

O altă funcționalitate a aplicației web este aceea de a căuta alți utilizatori prin
intermediul unui Search Bar (eng. bară de căutare) . Utilizatorul curent poate căuta formații
sau alți utilizatori prin intermediului câmpului de căutare din bara de navigare de tip
dropdown din partea superioară a pag inii. Restricția este de a se introduce cel puțin trei
litere pentru a se putea genera un rezultat. Este o unealtă facil de utilzat care va
redirecționa utilizatorul spre pagina de profil a celuilalt utilizator căutat. Contactele găsite
poartă atât numele cât și poza de profil a acestora pentru a fi mult mai ușor de identificat.
În caz că utilizatorul nu se află în baza de date, un mesaj sugestiv va fi afișat, No results
found (eng. niciun rezultat găsit).

Fig.28. Funcționalitatea de a căuta în aplicație utilizatori

Scopul acestei funcționalități este de a ușura interacțiunea cu alți utilizatori în caz
ca clientul principal are foarte mutle contacte în rețeaua de cunoștințe, sau dacă utilizatorul
este nou înregistrat pe platformă, și își formează cercul de prieteni.
După ce un utilizator a reușit să gasească persoana sau formația pe care îl/o căuta
acesta poate da click pe numele lor și aplicația îl va redirecționa pe pagina de profil a
persoanei/trupei în cauză.

42

Fig.29. Pagina de vizualizare a profilu rilor

Pe pagina de profil a fiecăuri utilizator vor fi afișate informațiile salvate la
autentificare sau ultima versiune de informații modificate din secțiunea de editare a
profilului. Utilizatorul care a căutat un alt client al aplicației are posibilitat ea, depinzând de
cauză, să trimită cerere de prietenie, să accepte cererea de prietenie din partea utilizatorului
căutat și, indiferent de starea de prietenie dintre cei doi, să comunice prin mesaje.
Butonul de Write UserName a message… va redirecționa utilizatorul spre pagina de
chat dintre cei doi, unde aceștia, utilizatorul curent și cel căutat își vor putea trimite unul
altuia mesaje.

43

Fig. 30. Pagina de gestionare a mesajelor

44

45 5. Concluzii și dezvoltări ulterioare

Obiectiv ul principal al acestui proiect a fost realizarea unei aplicații web de
socializare având ca public țintă artiștii din sfera domeniului muzical. Astfel că clienții
aplicației își pot forma grupuri de prieteni, pot crea evenimente la care să participe în mod
colectiv. De asemenea este facilitată colaborarea între artiști, toate acestea fiind realizate
prin intermediul unei aplicații intuitive, scalabile și cu un potențial de dezvoltare ulterioară
atât din punct de vedere al funcționalităților cât și din punct de vedere al utilizat orilor.
Eventualii doritori se pot înregistra și autentifica în pagină de unde pot lua contact
cu diverși alți artiști ce folosesc aplicația VAL.
În dezvoltarea aplicației VAL au fost folosite diverse tehnologii de ultimă generație
cu foarte mare suport ș i răspândire în domeniul IT, de asemenea cum aplicația are la bază
arhitectura REST aceasta poate fi foarte ușor extinsă către diverse alte platforme, de
exemplu iOS, Android, Windows Phone etc.
Din punct de vedere al versatilității aplicației aceasta a fo st dezvoltată folosind
tehnologia .NET Core 2 care are avantajul protabilității, astfel că în mediul industrial
aplicația poate fi găzduită pe orice tip de server, cum ar fi Linux, MacOS sau Windows,
deci platforma de hosting de server să nu reprezinte o c onstrângere în ceea ce privește
performanța și mentenanța aplicației.
În ceea ce privește dezvoltările ulterioare aplicația ar putea beneficia de o
implementare de algoritm de tip machine learning care să sugereze utilizatorului diverși
alti potențiali pr ieteni, bazat pe interesele muzicale și/sau evenimentele la care aceștia au
participat. Totodată bazat pe același sistem similar de predicție se por sugera diverse
evenimente pentru anumite grupuri de utilizatori, cum ar fi evenimente cu scopul de a
atrage formații/interpreți tineri în deschidere, popularizarea unor festivaluri/concerte șamd.
Mai mult aplicația ar putea beneficia și de un serviciu de notificări care să afișeze în
timp real modificările care interacționează direct cu actorul principal. Se m ai pot adăuga de
asemenea și emoticoane, pentru a personaliza și mai mult serviciul de mesagerie al
platformei. De asemenea, legat tot de serviciul de mesagerie, se poate implementa un
sistem de apel bazat pe VoIP care să faciliteze și mai mult interacțiun ea între utilizatori.
În final, aplicația are un real potențial de dezvoltare și potențial crescut de a deveni
populară în special în rândul publicului țintă, dar și în rândul aspiranților.

46

47
6. Bibliografie

[1] – Alejandro Rjoia The Evolution and Hi story of Blogging: Where it Began and Where
it is Now – https://alejandrorioja.com/blog/history -of-blogging/
[2] – Keith Terrell – The History of Social Media: Social Networking Evoluti on! –
https://historycooperative.org/the -history -of-social -media/
[3] – Sarah Phillips – A brief history of Facebook –
https://www.theguardian.com/technology/2007/jul/25/media.newmedia
[4] – Avi Kishundat – A Brief Overview and History of LinkedIn –
https://candybitsocial.com/news/hist ory-of-linkedin
[5] – Steve Longo – How much is Facebook worth? –
https://www.dailymail.co.uk/sciencetech/facebook/article -6008395/How -Facebook –
worth.h tml
[6] – Associate Press International Business Times – Remember LinkedIn? A year on from
the $27bn Microsoft takeover – was it worth it? – https://www.ibtimes.co.uk/remember –
linkedin -year-27bn -microsoft -takeover -was-it-worth -it-1658136
[7] – statista.com Number of social media users worldwide from 2010 to 2021 (in billions)
– https://www.statista.com/statistics/278414/number -of-worldwide -social -network -users/
[8] – Alexander E.M. Hess – 10 fastest -growing jobs in the USA –
https://eu.usatoday.com/story/money/business/2013/09/02/10 -fastest -growing -jobs-in-
usa/2750169/
[9] – Tom Dykstra – Implementing the Repository and Unit of Work Patterns in an
ASP.NET MVC Application – https://docs.microsoft.com/en –
us/aspnet/mvc/overview/older -versio ns/getting -started -with-ef-5-using -mvc-
4/implementing -the-repository -and-unit-of-work -patterns -in-an-asp-net-mvc-application
[10] – jQuery API Documentation – https://api.jquery.com/
[11] – Benjamin Utterback – What is Bootstrap? – The History and the Hype –
https://www.prestashop.com/en/blog/what -is-bootstrap
[12] – Steve Burge – https://www.ostraining.com/blog/webdesign/bootstrap -popular/
[13] – Roy Fielding, 2000, – Architectural Styles and the Design of Network -based
Software Architectures – https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
[14] – Joseph Benharosh – What is REST API? in plain English –
https://phpenthusiast.com/blog/what -is-rest-api
[15] – Margaret Rouse – six degrees of separation –
https://whatis.techtarget.com/definition/six -degrees -of-separation