Differences
This shows you the differences between two versions of the page.
|
pw:laboratoare:02 [2023/02/23 11:33] ciprian.dobre [Baza de date si ORM] |
pw:laboratoare:02 [2023/03/13 18:00] (current) ciprian.dobre [Dependency injection] |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| Un motiv pentru care limbaje cum sunt Java si C# sunt populare pentru dezvoltarea de aplicatii este faptul ca suporta reflexie la runtime, adica programul la runtime poate face introspectie si poate, de exemplu, sa creeze instante de obiecte fara sa fie explicit programat in acest sens. | Un motiv pentru care limbaje cum sunt Java si C# sunt populare pentru dezvoltarea de aplicatii este faptul ca suporta reflexie la runtime, adica programul la runtime poate face introspectie si poate, de exemplu, sa creeze instante de obiecte fara sa fie explicit programat in acest sens. | ||
| - | Acest lucru a ajutat la implementarea de dependency injection in aceste limbaje ce se rezuma doar la faptul ca la runtime componentele sunt instantiate rand pe rand de la cele mai simple la cele mai complexe iar instantele componenteleor sunt pasate ca paramentri pentru instantierea altor componente. | + | Acest lucru a ajutat la implementarea de dependency injection in aceste limbaje ce se rezuma doar la faptul ca la runtime componentele sunt instantiate rand pe rand de la cele mai simple la cele mai complexe iar instantele componentelor sunt pasate ca paramentri pentru instantierea altor componente. |
| In exemplul de mai jos se poate vedea cum este declaranta o componeta, parametri dati la constructor sunt pasati de framework atunci cand se cere aceasta componenta, observati ca parametri sunt interfete. De obicei se injecteaza interfete, nu implementari efective motivul fiind ca pot exista mai multe implementari pentru o interfata care pot fi schimbate in functie de necesitati cum ar fi pentru testare, de exemplu se poate inlocui implementarea de productie cu una de test pentru interceptarea apelurilor de metode ale acelui serviciu. | In exemplul de mai jos se poate vedea cum este declaranta o componeta, parametri dati la constructor sunt pasati de framework atunci cand se cere aceasta componenta, observati ca parametri sunt interfete. De obicei se injecteaza interfete, nu implementari efective motivul fiind ca pot exista mai multe implementari pentru o interfata care pot fi schimbate in functie de necesitati cum ar fi pentru testare, de exemplu se poate inlocui implementarea de productie cu una de test pentru interceptarea apelurilor de metode ale acelui serviciu. | ||
| Line 69: | Line 69: | ||
| De mentionat, exista 3 tipuri de lifetime pentru instantele componentelor, anume: | De mentionat, exista 3 tipuri de lifetime pentru instantele componentelor, anume: | ||
| * **Singleton** – pe durata programului doar o singura instanta a acelei componente este instantiata, de fiecare data cand se cere componenta aceiasi instanta este returnata. Un exmplu este ILogger care este instantiat o singura data pentru fiecare parametru generic. | * **Singleton** – pe durata programului doar o singura instanta a acelei componente este instantiata, de fiecare data cand se cere componenta aceiasi instanta este returnata. Un exmplu este ILogger care este instantiat o singura data pentru fiecare parametru generic. | ||
| - | * **Transient** – de fiecare data cand se cere o componenta se returneaza o noua instanta. Exemple de componente transient sunt controllerele, la fiecare cerere HTTP o noua instanta de controller este create pentru tratarea cererii. | + | * **Transient** – de fiecare data cand se cere o componenta se returneaza o noua instanta. Exemple de componente transient sunt controllerele, la fiecare cerere HTTP o noua instanta de controller este creata pentru tratarea cererii. |
| * **Scoped** – instantele returnate sunt unice pe fiecare scope. Un exemplu este contextul de baza de date. | * **Scoped** – instantele returnate sunt unice pe fiecare scope. Un exemplu este contextul de baza de date. | ||
| Line 194: | Line 194: | ||
| <code>dotnet ef migrations add <nume_migrare> --context <nume_clasa_context> --project <proiect_cu_migrarile> --startup-project <proiect_cu_startup></code> | <code>dotnet ef migrations add <nume_migrare> --context <nume_clasa_context> --project <proiect_cu_migrarile> --startup-project <proiect_cu_startup></code> | ||
| - | In codul din laborator migrarile o data create for fi aplicate automat la prima cerere facuta catre baza de date. | + | In codul din laborator migrarile o data create for fi aplicate automat la prima cerere facuta catre baza de date. Pentru mai multe informatii despre migrari si uneltele in linie de comanda puteti consulta documentatia de [[https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/?tabs=dotnet-core-cli|aici]]. |
| ===== Informatii suplimentare pentru cine doreste ===== | ===== Informatii suplimentare pentru cine doreste ===== | ||
| + | |||
| Pentru .NET ORM-ul se numeste Entity Framework si ca o particularitate acesta nu se foloseste de cereri SQL scrise de programator ci se pot specifica functional prin **LINQ** (**L**anguage **In**tegrated **Q**uery), framework-ul abstractizeaza prin interfata functionala cererile iar acestea sunt traduse in cereri specifice pentru fiecare tip de baza de date. | Pentru .NET ORM-ul se numeste Entity Framework si ca o particularitate acesta nu se foloseste de cereri SQL scrise de programator ci se pot specifica functional prin **LINQ** (**L**anguage **In**tegrated **Q**uery), framework-ul abstractizeaza prin interfata functionala cererile iar acestea sunt traduse in cereri specifice pentru fiecare tip de baza de date. | ||
| Mai jos e un exemplu de cum se traduce codul din LINQ in SQL de Postgres. | Mai jos e un exemplu de cum se traduce codul din LINQ in SQL de Postgres. | ||
| <code> | <code> | ||
| var search = "test"; | var search = "test"; | ||
| - | await DbContext.Set<UserFile>().Where(e => EF.Functions.Like(e.Name, $"%{search}%")).OrderByDescending(e => e.CreatedAt).Select(e => new UserFileDTO | + | await DbContext.Set<UserFile>() |
| + | .Where(e => EF.Functions.Like(e.Name, $"%{search}%")) | ||
| + | .OrderByDescending(e => e.CreatedAt) | ||
| + | .Select(e => new UserFileDTO | ||
| { | { | ||
| Id = e.Id, | Id = e.Id, | ||
| Line 220: | Line 224: | ||
| <code> | <code> | ||
| select uf."Id", uf."Name", uf."Description", uf."CreatedAt", uf."UpdatedAt", u."Id", u."Email", u."Name", u."Role" from "UserFile" uf | select uf."Id", uf."Name", uf."Description", uf."CreatedAt", uf."UpdatedAt", u."Id", u."Email", u."Name", u."Role" from "UserFile" uf | ||
| - | join "User" u on u."Id" = uf."UserId" | + | left join "User" u on u."Id" = uf."UserId" |
| where uf."Name" like '%test%' | where uf."Name" like '%test%' | ||
| order by uf."CreatedAt" desc | order by uf."CreatedAt" desc | ||
| Line 227: | Line 231: | ||
| In LINQ metodele pe setul de baza de date sunt in coresondenta unu la unu cu cele din SQL, **proiectia/select** corespunde la .**Select**, **filtrarea/where** corespunde la **.Where** si **sortarea/order** la **.OrderBy**. | In LINQ metodele pe setul de baza de date sunt in coresondenta unu la unu cu cele din SQL, **proiectia/select** corespunde la .**Select**, **filtrarea/where** corespunde la **.Where** si **sortarea/order** la **.OrderBy**. | ||
| - | Astfel, folosind un ORM se pot implementa componente de tip repository care fie sa interactioneaze cu ORM-ul pe entitati specifice cum ar fi entitatea pentru utilizatori la fel cum sunt serviciile sau sa fie generice iar cererile sa fie grupate in design pattern-ul de specificatii. O specificatie in contextul de design pattern este un obiect care contine cererea catre baza de date pentru a fi refolosita in mai multe parti ale codului. | + | Astfel, folosind un ORM se pot implementa componente de tip **repository** care fie sa interactioneaze cu ORM-ul pe entitati specifice cum ar fi entitatea pentru utilizatori sau sa fie generice iar cererile sa fie grupate in design pattern-ul de **specificatii**. O specificatie in contextul de design pattern este un obiect care contine cererea catre baza de date pentru a fi refolosita in mai multe parti ale codului. Puteti vedea in codul din laborator cum sunt implementate specificatiile si repository-ul generic. |
| Un lucru foarte important de stiut aici e ca entitatiile odata extrase din baza de date sunt legate implicit la contextul bazei de date si sunt urmarite de framework, aceste enitati sunt numite **“tracked”**, si nu vor fi consumate de garbage collector decat dupa ce contextul bazei de date este consumat mai intai. | Un lucru foarte important de stiut aici e ca entitatiile odata extrase din baza de date sunt legate implicit la contextul bazei de date si sunt urmarite de framework, aceste enitati sunt numite **“tracked”**, si nu vor fi consumate de garbage collector decat dupa ce contextul bazei de date este consumat mai intai. | ||
| Line 233: | Line 237: | ||
| Este nerecomandat sa fie expuse entitatile bazei de date in controller, de aceia cel mai bine este ca entitatile sa fie transformate/mapate in **DTO**-uri (**Data Transfer Objects**), adica obiecte simple care doar transfera informatiile din entitati si care pot fi consumate de garbage colletor independent de contextul bazei de date. De asemenea, nu toate informatiile din entitate pot fi necesare sau se doresc a fi expuse in fara serviciilor si este mai bine sa fie folosite DTO-uri si pentru securitatea aplicatiei. | Este nerecomandat sa fie expuse entitatile bazei de date in controller, de aceia cel mai bine este ca entitatile sa fie transformate/mapate in **DTO**-uri (**Data Transfer Objects**), adica obiecte simple care doar transfera informatiile din entitati si care pot fi consumate de garbage colletor independent de contextul bazei de date. De asemenea, nu toate informatiile din entitate pot fi necesare sau se doresc a fi expuse in fara serviciilor si este mai bine sa fie folosite DTO-uri si pentru securitatea aplicatiei. | ||
| - | Pentru a clarifica, contextul bazei de date este o conectiune cu baza de date si un cache pentru entitati si cereri. | + | ===== Sarcini laborator ===== |
| + | |||
| + | Descarcati codul din laborator de pe [[https://gitlab.com/mobylabwebprogramming/dotnetbackend|Gitlab]] si urmatiti urmatoarele tipuri de clase: | ||
| + | * Entitati | ||
| + | * Configurari de entitati | ||
| + | * Specificatii | ||
| + | * Repository | ||
| + | |||
| + | Creati prima migrare numita **InitialCreate** cu comanda de **dotnet-ef** si rulati proiectul cu baza de date pornita. Conectati-va la baza de date si urmariti schema bazei de date. | ||
| + | |||
| + | Incercati sa adaugati propriile entitati si creati noi migrari. Puteti de acum sa va creati schema bazei de date pentru proiect. | ||
