Sådan bruges dataoverførselsobjekter i ASP.NET Core 3.1

Et dataoverførselsobjekt (almindeligvis kendt som en DTO) er normalt en forekomst af en POCO-klasse (almindelig gammel CLR-objekt), der bruges som en container til at indkapsle data og videregive dem fra et lag af applikationen til et andet. Du finder typisk DTO'er, der bruges i servicelaget til at returnere data tilbage til præsentationslaget. Den største fordel ved at bruge DTO'er er at frakoble klienter fra dine interne datastrukturer.

Denne artikel diskuterer, hvorfor vi skal bruge dataoverførselsobjekter, og hvordan vi kan arbejde med dem i ASP.NET Core 3.1. For at arbejde med kodeeksemplerne i denne artikel skal du have Visual Studio 2019 installeret i dit system. Hvis du ikke allerede har en kopi, kan du downloade Visual Studio 2019 her.

Opret et ASP.NET Core 3.1 API-projekt

Lad os først starte med at oprette et ASP.NET Core-projekt i Visual Studio. Forudsat at Visual Studio 2019 er installeret i dit system, skal du følge trinene beskrevet nedenfor for at oprette et nyt ASP.NET Core API-projekt i Visual Studio.

Start Visual Studio IDE.
Klik på "Opret nyt projekt."
I vinduet "Opret nyt projekt" skal du vælge "ASP.NET Core Web Application" fra listen over de viste skabeloner.
Klik på Næste.
I vinduet "Konfigurer dit nye projekt" skal du angive navnet og placeringen for det nye projekt.
Klik på Opret.
I vinduet "Opret ny ASP.NET Core-webapplikation", der vises derefter, skal du vælge .NET Core som runtime og ASP.NET Core 3.1 (eller nyere) fra rullelisten øverst.
Vælg “API” som projektskabelon for at oprette en ny ASP.NET Core API-applikation.
Sørg for, at afkrydsningsfelterne "Aktivér Docker-support" og "Konfigurer til HTTPS" ikke er markeret, da vi ikke bruger disse funktioner her.
Sørg for, at godkendelse er indstillet som "Ingen godkendelse", da vi heller ikke bruger godkendelse.
Klik på Opret.

Dette opretter et nyt ASP.NET Core API-projekt i Visual Studio. Vi bruger dette projekt til at arbejde med dataoverførselsobjekter i de efterfølgende afsnit i denne artikel.

Hvorfor bruge dataoverførselsobjekter (DTO'er)?

Når du designer og udvikler en applikation, hvis du bruger modeller til at videregive data mellem lagene og sende data tilbage til præsentationslaget, udsætter du de interne datastrukturer i din applikation. Det er en stor designfejl i din applikation.

Ved at afkoble dine lag gør DTO'er livet nemmere, når du implementerer API'er, MVC-applikationer og også beskedmønstre som Message Broker. En DTO er et godt valg, når du gerne vil føre et let objekt over ledningen - især når du passerer dit objekt via et medium, der er begrænset til båndbredde.

Brug DTO'er til abstraktion

Du kan drage fordel af DTO'er til at abstrakte domæneobjekterne i din applikation fra brugergrænsefladen eller præsentationslaget. Dermed afkobles præsentationslaget for din applikation fra servicelaget. Så hvis du vil ændre præsentationslaget, kan du gøre det let, mens applikationen fortsætter med at arbejde med det eksisterende domænelag. På samme måde kan du ændre domænelaget i din applikation uden at skulle ændre applikationspræsentationslaget.

Brug DTO'er til dataskydning

En anden grund til, at du gerne vil bruge DTO'er, er dataskydning. Ved at bruge DTO'er kan du kun returnere de anmodede data. Antag som et eksempel, at du har en metode ved navn GetAllEmployees (), der returnerer alle data vedrørende alle medarbejdere. Lad os illustrere dette ved at skrive en kode.

I det projekt, vi oprettede tidligere, skal du oprette en ny fil kaldet Employee.cs. Skriv følgende kode inde i denne fil for at definere en modelklasse med navnet Employee.

offentlig klasse medarbejder
    {
  public int Id {get; sæt; }
  offentlig streng Fornavn {get; sæt; }
  public string LastName {get; sæt; }
  public string DepartmentName {get; sæt; }
  offentlig decimal Grundlæggende {get; sæt; }
  offentlig decimal DA {get; sæt; }
  offentlig decimal HRA {get; sæt; }
  offentlig decimal NetSalary {get; sæt; }
    }

Bemærk, at medarbejderklassen indeholder egenskaber, herunder Id, FirstName, LastName, Department, Basic, DA, HRA og NetSalary. Præsentationslaget har dog muligvis kun brug for id, fornavn, efternavn og afdelingsnavn for medarbejderne fra GetAllEmployees () -metoden. Hvis denne metode returnerer en liste, vil enhver kunne se lønoplysningerne for en medarbejder. Du vil ikke have det.

For at undgå dette problem kan du designe en DTO-klasse med navnet EmployeeDTO, der kun indeholder de ønskede egenskaber (såsom Id, Fornavn, Efternavn og Afdelingsnavn).

Opret en DTO-klasse i C #

For at opnå dette skal du oprette en fil med navnet EmployeeDTO.cs og skrive følgende kode derinde.

offentlig klasse EmployeeDTO
    {
        public int Id {get; sæt; }
        offentlig streng Fornavn {get; sæt; }
        public string LastName {get; sæt; }
        public string DepartmentName {get; sæt; }
    }

Nu, hvor model- og dataoverførselsobjektklasserne er tilgængelige, kan du oprette en konvertererklasse, der indeholder to metoder: en til at konvertere en forekomst af medarbejdermodelklassen til en forekomst af EmployeeDTO og (omvendt) en til at konvertere en forekomst af EmployeeDTO til en forekomst af klassen Employee model. Du kan også drage fordel af AutoMapper, et populært objekt-til-objekt kortlægningsbibliotek til at kortlægge disse to forskellige typer. Du kan læse mere om AutoMapper her.

Du skal oprette en liste i servicelaget i din applikation og returnere samlingen tilbage til præsentationslaget.

Uforanderlighed af DTO'er

En DTO er beregnet til at transportere data fra et lag af en applikation til et andet lag. Forbrugeren af en DTO kan være indbygget i .NET / C # / Java eller endda JavaScript / TypeScript. En DTO serieres ofte, så den kan være uafhængig af den teknologi, der bruges i modtageren. I de fleste tilfælde behøver modtageren af data ikke at ændre disse data efter modtagelse - ideelt set burde det ikke!

Dette er et klassisk eksempel på betydningen af uforanderlighed. Og det er præcis, hvorfor en DTO skal være uforanderlig!

Der er flere måder, hvorpå du kan implementere uforanderlige DTO'er i C #. Du kan bruge en ReadOnlyCollection eller de trådsikre uforanderlige samlingstyper, der findes i System.Collections.Immutable namespace. Du kan drage fordel af pladetyper i C # 9 til også at implementere uforanderlige DTO'er.

Domænedrevet design forventer, at domæneobjekterne ikke kan ændres eksternt. Dette er en god grund til at gøre dine DTO'er uforanderlige, ikke?

DTO-serialiseringsudfordringer

Du skal være i stand til at serie- / deserialisere en DTO problemfrit, så den kan føres ned gennem ledningen. I praksis er du dog muligvis nødt til at løse nogle serialiseringsproblemer, når du arbejder med DTO'er. Du kan have flere enheder eller modelklasser i en applikation i den virkelige verden, og hver af dem kan indeholde referencer til hinanden.

Lad os sige, at du har opbygget et tilstedeværelsesstyringssystem for medarbejderne i din organisation. Typisk har du muligvis en klasse kaldet medarbejder i din applikation, der refererer til brugerklassen (dvs. en medarbejder er en bruger af applikationen), som igen refererer til rolleklassen. Rolleklassen henviser muligvis til tilladelseklassen, som igen kan henvise til klasserne PermissionType og PermissionGroup. Når du nu serierer en forekomst af medarbejderklassen, ender du også med at serieisere disse objekter. Det er let at se, at du i nogle komplicerede tilfælde kan ende med at serialisere flere typer.

Det er her, doven belastning eller asynkron belastning kommer til undsætning. Dette er en funktion, der kun kan hjælpe dig med at indlæse enheder, når du bliver bedt om det. For mere information om, hvordan man udfører doven indlæsning, kan du se på min artikel om doven initialisering i C #.

Dataoverførselsobjekter indeholder typisk ingen forretningslogik - de indeholder kun data. Uforanderlighed er en ønsket funktion, når man arbejder med DTO'er. Der er flere måder, hvorpå du kan implementere uforanderlige DTO'er. Jeg vil diskutere mere om uforanderlighed i C # i et senere indlæg her.