Hvordan bruke dataoverføringsobjekter i ASP.NET Core 3.1

Et dataoverføringsobjekt (ofte kjent som en DTO) er vanligvis en forekomst av en POCO (vanlig gammel CLR-objekt) -klasse som brukes som en beholder for å kapsle inn data og overføre dem fra ett lag av applikasjonen til et annet. Du vil vanligvis finne DTO-er som brukes i tjenestelaget for å returnere data tilbake til presentasjonslaget. Den største fordelen med å bruke DTO er å koble klienter fra dine interne datastrukturer.

Denne artikkelen diskuterer hvorfor vi skal bruke dataoverføringsobjekter og hvordan vi kan jobbe med dem i ASP.NET Core 3.1. For å jobbe med kodeeksemplene som er gitt i denne artikkelen, bør du ha Visual Studio 2019 installert på systemet ditt. Hvis du ikke allerede har en kopi, kan du laste ned Visual Studio 2019 her.

Opprett et ASP.NET Core 3.1 API-prosjekt

Først og fremst, la oss lage et ASP.NET Core-prosjekt i Visual Studio. Forutsatt at Visual Studio 2019 er installert i systemet ditt, følger du trinnene som er beskrevet nedenfor for å opprette et nytt ASP.NET Core API-prosjekt i Visual Studio.

Start Visual Studio IDE.
Klikk på "Opprett nytt prosjekt."
I vinduet "Opprett nytt prosjekt" velger du "ASP.NET Core Web Application" fra listen over malene som vises.
Klikk på Neste.
I vinduet "Konfigurer ditt nye prosjekt" angir du navnet og stedet for det nye prosjektet.
Klikk på Opprett.
I vinduet "Opprett nytt ASP.NET Core Web Application" som vises, velger du .NET Core som kjøretid og ASP.NET Core 3.1 (eller senere) fra rullegardinlisten øverst.
Velg “API” som prosjektmal for å opprette et nytt ASP.NET Core API-program.
Forsikre deg om at avmerkingsboksene "Aktiver Docker-støtte" og "Konfigurer for HTTPS" ikke er merket av da vi ikke bruker disse funksjonene her.
Forsikre deg om at autentisering er angitt som “ingen godkjenning”, da vi heller ikke bruker autentisering.
Klikk på Opprett.

Dette vil opprette et nytt ASP.NET Core API-prosjekt i Visual Studio. Vi bruker dette prosjektet til å jobbe med dataoverføringsobjekter i de påfølgende delene av denne artikkelen.

Hvorfor bruke dataoverføringsobjekter (DTO)?

Når du bruker modeller for å sende data mellom lagene og sender data tilbake til presentasjonslaget når du designer og utvikler et program, utsetter du de interne datastrukturene i applikasjonen. Det er en stor designfeil i applikasjonen din.

Ved å frakoble lagene dine gjør DTO-er livet enklere når du implementerer API-er, MVC-applikasjoner og også meldingsmønstre som Message Broker. En DTO er et godt valg når du ønsker å føre et lett objekt over ledningen - spesielt når du passerer objektet ditt via et medium som er båndbreddebegrenset.

Bruk DTO-er for abstraksjon

Du kan dra nytte av DTO-er for å trekke ut domeneobjektene til applikasjonen din fra brukergrensesnittet eller presentasjonslaget. Ved å gjøre dette blir presentasjonslaget til applikasjonen frakoblet tjenestelaget. Så hvis du vil endre presentasjonslaget, kan du gjøre det enkelt mens applikasjonen vil fortsette å jobbe med det eksisterende domenelaget. På samme måte kan du endre domenelaget i applikasjonen din uten å måtte endre presentasjonslaget til applikasjonen.

Bruk DTOer for skjuling av data

En annen grunn til at du vil bruke DTO-er, er skjuling av data. Det vil si at ved å bruke DTO kan du bare returnere de forespurte dataene. Anta for eksempel at du har en metode som heter GetAllEmployees () som returnerer alle dataene som gjelder alle ansatte. La oss illustrere dette ved å skrive litt kode.

I prosjektet vi opprettet tidligere, opprett en ny fil kalt Employee.cs. Skriv følgende kode i denne filen for å definere en modellklasse med navnet Employee.

offentlig klasse Ansatt
    {
  offentlig int Id {get; sett; }
  offentlig streng Fornavn {get; sett; }
  offentlig streng Etternavn {get; sett; }
  offentlig streng Avdelingsnavn {get; sett; }
  offentlig desimal Basic {get; sett; }
  offentlig desimal DA {get; sett; }
  offentlig desimal HRA {get; sett; }
  offentlig desimal NetSalary {get; sett; }
    }

Merk at medarbeiderklassen inneholder egenskaper, inkludert Id, fornavn, etternavn, avdeling, grunnleggende, DA, HRA og NetSalary. Presentasjonslaget trenger imidlertid kanskje bare ID, fornavn, etternavn og avdelingsnavn for de ansatte fra GetAllEmployees () -metoden. Hvis denne metoden returnerer en liste, vil noen kunne se lønnsopplysningene til en ansatt. Du vil ikke ha det.

For å unngå dette problemet, kan du designe en DTO-klasse med navnet EmployeeDTO som bare inneholder de egenskapene som er forespurt (for eksempel Id, Fornavn, Etternavn og Avdelingsnavn).

Lag en DTO-klasse i C #

For å oppnå dette, opprett en fil med navnet EmployeeDTO.cs og skriv følgende kode der.

offentlig klasse EmployeeDTO
    {
        offentlig int Id {get; sett; }
        offentlig streng Fornavn {get; sett; }
        offentlig streng Etternavn {get; sett; }
        offentlig streng Avdelingsnavn {get; sett; }
    }

Nå som modell- og dataoverføringsobjektklassene er tilgjengelige, vil du kanskje opprette en omformerklasse som inneholder to metoder: en for å konvertere en forekomst av medarbeidermodellklassen til en forekomst av EmployeeDTO og (omvendt) en for å konvertere en forekomst av EmployeeDTO til en forekomst av klassen Employee model. Du kan også dra nytte av AutoMapper, et populært objekt-til-objekt-kartbibliotek for å kartlegge disse to forskjellige typene. Du kan lese mer om AutoMapper her.

Du bør opprette en liste i tjenestelaget til applikasjonen din og returnere samlingen tilbake til presentasjonslaget.

Uforanderlighet av DTOer

En DTO er ment å transportere data fra ett lag i et program til et annet lag. Forbrukeren av en DTO kan være bygget i .NET / C # / Java eller til og med JavaScript / TypeScript. En DTO serieres ofte slik at den kan være uavhengig av teknologien som brukes i mottakeren. I de fleste tilfeller trenger ikke mottakeren av dataene å modifisere dataene etter mottakelse - ideelt sett burde det ikke!

Dette er et klassisk eksempel på viktigheten av uforanderlighet. Og det er nøyaktig hvorfor en DTO skal være uforanderlig!

Det er flere måter du kan implementere uforanderlige DTO-er i C #. Du kan bruke en ReadOnlyCollection eller trådsikre uforanderlige samlingstyper som er tilstede i System.Collections.Immutable namespace. Du kan dra nytte av platetypene i C # 9 for å implementere uforanderlige DTOer også.

Domenedrevet design forventer at domeneobjektene skal være uforanderlige. Dette er en god grunn til å gjøre DTO-ene dine uforanderlige, ikke sant?

DTO-serialiseringsutfordringer

Du bør kunne serialisere / deserialisere en DTO sømløst slik at den kan føres nedover ledningen. I praksis må du imidlertid løse noen serialiseringsproblemer når du arbeider med DTO-er. Du kan ha flere enheter eller modellklasser i en applikasjon fra den virkelige verden, og hver av dem kan ha referanser til hverandre.

La oss si at du har bygget et system for fremmøtehåndtering for de ansatte i organisasjonen din. Vanligvis kan det være at du har en klasse som heter Ansatt i applikasjonen din som refererer til brukerklassen (dvs. en ansatt er en bruker av applikasjonen) som igjen refererer til rolleklassen. Rolleklassen kan referere til tillatelseklassen som igjen kan referere til PermissionType- og PermissionGroup-klassene. Nå, når du serierer en forekomst av medarbeiderklassen, vil du også ende opp med å serieisere disse objektene. Det er lett å se at du i noen kompliserte tilfeller kan ende opp med å serieisere flere typer.

Det er her lat belastning eller asynkron belastning kommer til unnsetning. Dette er en funksjon som bare kan hjelpe deg med å laste inn enheter når du blir bedt om det. For mer informasjon om hvordan du utfører lat lasting, kan du ta en titt på artikkelen min om lat initialisering i C #.

Dataoverføringsobjekter inneholder vanligvis ingen forretningslogikk - de inneholder bare data. Uforanderlighet er en ønsket funksjon når du arbeider med DTO. Det er flere måter du kan implementere uforanderlige DTO-er på. Jeg vil diskutere mer om uforanderlighet i C # i et senere innlegg her.