Scopul acestui laborator este de a va familiariza cu un concept foarte important in dezvoltarea aplicatiilor in general, anume Dependency injection, dar de asemenea sa va familiazati si interactiunea cu baza de date folosind un ORM.

Pentru acest laborator o sa aveti nevoie sa descarcati si sa urmariti indicatiile din codul de pe Gitlab.

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 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.

public class InitializerWorker : BackgroundService
{
    private readonly ILogger<InitializerWorker> _logger;
    private readonly IServiceProvider _serviceProvider;

    public InitializerWorker(ILogger<InitializerWorker> logger, IServiceProvider serviceProvider)
    {
        _logger = logger; \\ The logger instance is injected here.
        _serviceProvider = serviceProvider; \\ Here the service provider is injected to request other components on runtime at request.
    }

    protected override async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        try
        {
            await using var scope = _serviceProvider.CreateAsyncScope(); \\ Here a new scope is created, this is useful to get new scoped instances.
            var userService = scope.ServiceProvider.GetService<IUserService>(); \\ Here an instance for a service is requested, 
                                                                                \\ it may fail if the component is not declared or an exception
                                                                                \\ is thrown on it’s creation.

            if (userService == null)
            {
                _logger.LogInformation("Couldn't create the user service!");

                return;
            }

            var count = await userService.GetUserCount(cancellationToken);

            if (count.Result == 0)
            {
                _logger.LogInformation("No user found, adding default user!");

                await userService.AddUser(new()
                {
                    Email = "admin@default.com",
                    Name = "Admin",
                    Role = UserRoleEnum.Admin,
                    Password = PasswordUtils.HashPassword("default")
                }, cancellationToken: cancellationToken);
            }
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "An error occurred while initializing database!");
        }
    }
}

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.
• 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.

Mai jos este un exemplu de cum se pot declara serviciile ca si componente transiente, fiecare serviciu implementeaza propria interfata, intefata practic este cheia de cautare pentru un serviciu. Serviciile sunt declarate adaugandu-le la configurarea builder-ului de applicatie in colectia de servicii.

        builder.Services
            .AddTransient<IUserService, UserService>()
            .AddTransient<ILoginService, LoginService>()
            .AddTransient<IFileRepository, FileRepository>()
            .AddTransient<IUserFileService, UserFileService>()
            .AddTransient<IMailService, MailService>();

Pe langa logica aplicatiei, si vom discuta la laboratoarele urmatoare cum se implementeaza, trebuie sa existe persistenta datelor peste care se efectueaza logica efectiva. In acest sens majoritatea aplicatiilor folosesc baze de date, pentru a simplifica interactiunea programelor cu baza de date au fost implementate ORM-uri (Object-relational mapping), acestea sunt framework-uri care fac o corespondenta a tabelelor si a tipurilor de date din baza de date cu obiectele, numite entitati, si tipurile declarate in codul aplicatiei.

ORM-urile expun in general o interfata generica care poate fi folosita pentru mai multe baze de date (PostgreSQL, MariaDB sau SQLServer) folosind acelasi cod chiar daca pot exista particularizari pentru fiecare, aceste implementari specifice se gasesc in divese biblioteci de pe NuGet. Interfata generica este expusa printr-un context de baza de date, contextul nu este altceva decat un client pentru baza de date care serializaza/deserializeaza cereri si obiecte si mai serveste ca cache pentru entitati, in .NET contextul o sa fie o clasa derivata de la DBContext.

Mai jos aveti un exemplu de corespondenta a unor entati cu tabele din baza de date.

public abstract class BaseEntity
{
    public Guid Id { get; set; }
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime UpdatedAt { get; set; } = DateTime.UtcNow;
    public void UpdateTime() => UpdatedAt = DateTime.UtcNow;
}
public class User : BaseEntity
{
    public string Name { get; set; } = default!;
    public string Email { get; set; } = default!;
    public string Password { get; set; } = default!;
    public UserRoleEnum Role { get; set; } = default!;
    public ICollection<UserFile> UserFiles { get; set; } = default!;
}
public class UserFile : BaseEntity
{
    public string Path { get; set; } = default!;
    public string Name { get; set; } = default!;
    public string? Description { get; set; }

    public Guid UserId { get; set; }
    public User User { get; set; } = default!;
}

Pentru fiecare entitate se creaza si o clasa de configurare pentru ca ORM-ul sa stie aditional diverse detalii cum ar fi ce proprietati corespund la chei primare, unice sau de referinta.

public class UserConfiguration : IEntityTypeConfiguration<User>
{
    public void Configure(EntityTypeBuilder<User> builder)
    {
        builder.Property(e => e.Id) // This specifies which property is configured.
            .IsRequired(); // Here it is specified if the property is required, meaning it cannot be null in the database.
        builder.HasKey(x => x.Id); // Here it is specifies that the property Id is the primary key.
        builder.Property(e => e.Name)
            .HasMaxLength(255) // This specifies the maximum length for varchar type in the database.
            .IsRequired();
        builder.Property(e => e.Email)
            .HasMaxLength(255)
            .IsRequired();
        builder.HasAlternateKey(e => e.Email); // Here it is specifies that the property Email is a unique key.
        builder.Property(e => e.Password)
            .HasMaxLength(255)
            .IsRequired();
        builder.Property(e => e.Role)
            .HasMaxLength(255)
            .IsRequired();
        builder.Property(e => e.CreatedAt)
            .IsRequired();
        builder.Property(e => e.UpdatedAt)
            .IsRequired();
    }
}

    public void Configure(EntityTypeBuilder<UserFile> builder)
    {
        builder.Property(e => e.Id)
            .IsRequired();
        builder.HasKey(x => x.Id);
        builder.Property(e => e.Path)
            .HasMaxLength(255)
            .IsRequired();
        builder.Property(e => e.Name)
            .HasMaxLength(255)
            .IsRequired();
        builder.Property(e => e.Description)
            .HasMaxLength(4095)
            .IsRequired(false); // This specifies that this column can be null in the database.
        builder.Property(e => e.CreatedAt)
            .IsRequired();
        builder.Property(e => e.UpdatedAt)
            .IsRequired();

        builder.HasOne(e => e.User) // This specifies a one-to-many relation.
            .WithMany(e => e.UserFiles) // This provides the reverse mapping for the one-to-many relation. 
            .HasForeignKey(e => e.UserId) // Here the foreign key column is specified.
            .HasPrincipalKey(e => e.Id) // This specifies the referenced key in the referenced table.
            .IsRequired()
            .OnDelete(DeleteBehavior.Cascade); // This specifies the delete behavior when the referenced entity is removed.
    }
}

Cand se implementeaza o schema de baza de date aceasta poate suferii diverse modificari in timpul dezvoltarii si maturizarii aplicatiei. Din acesta cauza, modificarile pe schema de baza de date trebuie sa fie efectuate incremental, adica orice modificare se aplica peste modificarile precedente, si de aceia exista conceptul de migrare. O migrare este o transformare, adesea reversibila, a schemei bazei de date care sa reflecte schimbarile din cod. In Entity Framework puteti folosi migrari instaland dotnet-ef:

dotnet tool install --global dotnet-ef --version 6.*

O data ce au fost create entitatile si configurate corespunzator (vedeti configurarile pentru entitati din din proiectul laboratorului) se poate rula comanda de generare a migrarilor avand baza de date deschisa:

dotnet ef migrations add <nume_migrare> --context <nume_clasa_context> --project <proiect_cu_migrarile> --startup-project <proiect_cu_startup>

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 aici.

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 (Language Integrated Query), 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.

        var search = "test";
        await DbContext.Set<UserFile>()
        .Where(e => EF.Functions.Like(e.Name, $"%{search}%"))
        .OrderByDescending(e => e.CreatedAt)
        .Select(e => new UserFileDTO
        {
            Id = e.Id,
            Name = e.Name,
            Description = e.Description,
            CreatedAt = e.CreatedAt,
            UpdatedAt = e.UpdatedAt,
            User = new()
            {
                Id = e.User.Id,
                Email = e.User.Email,
                Name = e.User.Name,
                Role = e.User.Role
            }
        }).ToListAsync(); 

Acest cod se traduce in urmatorul SQL.

select uf."Id", uf."Name", uf."Description", uf."CreatedAt", uf."UpdatedAt", u."Id", u."Email", u."Name", u."Role" from "UserFile" uf 
left join "User" u on u."Id" = uf."UserId" 
where uf."Name" like '%test%'
order by uf."CreatedAt" desc

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 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.

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.

Descarcati codul din laborator de pe 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.