Kako uporabljati predmete za prenos podatkov v ASP.NET Core 3.1

Predmet prenosa podatkov (splošno znan kot DTO) je običajno primerek razreda POCO (navadni stari objekt CLR), ki se uporablja kot vsebnik za enkapsulacijo podatkov in njihovo posredovanje iz ene plasti aplikacije v drugo. Običajno najdete DTO, ki se uporabljajo v storitveni plasti za vrnitev podatkov nazaj v predstavitveni sloj. Največja prednost uporabe DTO-jev je ločevanje odjemalcev od notranjih podatkovnih struktur.

V tem članku je razloženo, zakaj bi morali uporabljati predmete za prenos podatkov in kako lahko z njimi delamo v ASP.NET Core 3.1. Če želite delati s primeri kod v tem članku, morate imeti v sistemu nameščen Visual Studio 2019. Če kopije še nimate, lahko Visual Studio 2019 prenesete tukaj.

Ustvarite projekt API ASP.NET Core 3.1

Najprej ustvarimo projekt ASP.NET Core v Visual Studio. Ob predpostavki, da je Visual Studio 2019 nameščen v vašem sistemu, sledite spodnjim korakom, da v Visual Studio ustvarite nov projekt API-ja ASP.NET Core.

Zaženite Visual Studio IDE.
Kliknite »Ustvari nov projekt«.
V oknu »Ustvari nov projekt« na seznamu prikazanih predlog izberite »Spletna aplikacija ASP.NET Core«.
Kliknite Naprej.
V oknu »Konfiguriranje novega projekta« določite ime in mesto novega projekta.
Kliknite Ustvari.
V naslednjem oknu »Ustvari novo spletno aplikacijo ASP.NET Core« izberite .NET Core kot izvajalno okolje in ASP.NET Core 3.1 (ali novejšo) s spustnega seznama na vrhu.
Kot predlogo projekta izberite »API«, da ustvarite novo aplikacijo ASP.NET Core API.
Prepričajte se, da sta potrditveni polji »Omogoči podporo za Docker« in »Konfiguriranje za HTTPS« odstranjeni, saj tukaj ne bomo uporabljali teh funkcij.
Prepričajte se, da je preverjanje pristnosti nastavljeno na »Brez preverjanja pristnosti«, saj tudi preverjanja pristnosti ne bomo uporabljali.
Kliknite Ustvari.

To bo ustvarilo nov projekt API-ja ASP.NET Core v Visual Studio. Ta projekt bomo uporabili za delo z objekti za prenos podatkov v naslednjih oddelkih tega članka.

Zakaj uporabljati predmete za prenos podatkov (DTO)?

Če pri načrtovanju in razvoju aplikacije uporabljate modele za posredovanje podatkov med plastmi in pošiljanje podatkov nazaj v predstavitveni sloj, potem izpostavite notranje podatkovne strukture aplikacije. To je glavna napaka pri oblikovanju vaše prijave.

Z ločitvijo plasti DTO-ji olajšajo življenje pri implementaciji API-jev, aplikacij MVC in vzorcev sporočanja, kot je Message Broker. DTO je odlična izbira, če bi radi prenesli lahek predmet čez žico - še posebej, če predmet prenašate prek medija, ki ima omejeno pasovno širino.

Za abstrakcijo uporabite DTO

DTO lahko izkoristite za abstrakcijo domenskih predmetov vaše aplikacije iz uporabniškega vmesnika ali predstavitvene plasti. Pri tem je predstavitveni sloj vaše aplikacije ločen od storitvenega sloja. Torej, če želite spremeniti predstavitveni sloj, lahko to enostavno storite, medtem ko bo aplikacija še naprej delovala z obstoječo plastjo domene. Podobno lahko spremenite domensko plast aplikacije, ne da bi morali spremeniti predstavitveni sloj aplikacije.

Za skrivanje podatkov uporabite DTO

Drug razlog, zakaj bi želeli uporabiti DTO, je skrivanje podatkov. To pomeni, da lahko z uporabo DTO-jev vrnete samo zahtevane podatke. Za primer predpostavimo, da imate metodo z imenom GetAllEfficiees (), ki vrne vse podatke, ki se nanašajo na vse zaposlene. Ponazorimo to s pisanjem neke kode.

V projektu, ki smo ga ustvarili prej, ustvarite novo datoteko z imenom Employee.cs. V to datoteko vpišite naslednjo kodo, da definirate razred modela z imenom Employee.

javni razred Zaposlen
    {
  public int Id {get; set; }
  javni niz FirstName {get; set; }
  javni niz LastName {get; set; }
  javni niz DepartmentName {get; set; }
  javni decimalni Basic {get; set; }
  javni decimalni DA {get; set; }
  javna decimalna HRA {get; set; }
  javna decimalna NetSalary {get; set; }
    }

Upoštevajte, da razred Employee vsebuje lastnosti, vključno z Id, FirstName, LastName, Department, Basic, DA, HRA in NetSalary. Vendar pa predstavitveni sloj morda potrebuje samo identiteto, ime, priimek in ime oddelka zaposlenih iz metode GetAllEfficiees (). Če ta metoda vrne seznam, lahko kdor koli vidi podrobnosti o plači zaposlenega. Tega si ne želite.

Da bi se izognili tej težavi, lahko oblikujete razred DTO z imenom EmployeeDTO, ki bo vseboval samo zahtevane lastnosti (kot so Id, Ime, Priimek in Ime oddelka).

Ustvarite razred DTO v jeziku C #

Če želite to doseči, ustvarite datoteko z imenom EmployeeDTO.cs in vanjo vpišite naslednjo kodo.

javni razred EmployeeDTO
    {
        public int Id {get; set; }
        javni niz FirstName {get; set; }
        javni niz LastName {get; set; }
        javni niz DepartmentName {get; set; }
    }

Zdaj, ko so na voljo razredi modela in predmeta prenosa podatkov, boste morda želeli ustvariti pretvorniški razred, ki vsebuje dve metodi: eno za pretvorbo primerka razreda modela Employee v primerek EmployeeDTO in (obratno) enega za pretvorbo primerka of EmployeeDTO na primerek razreda modela Employee. Za preslikavo teh dveh različnih vrst lahko uporabite tudi AutoMapper, priljubljeno knjižnico preslikav od objekta do predmeta. Več o AutoMapperju si lahko preberete tukaj.

V servisni plasti aplikacije morate ustvariti seznam in zbirko vrniti nazaj v predstavitveni sloj.

Nespremenljivost DTO

DTO je namenjen prenosu podatkov iz ene plasti aplikacije v drugo plast. Potrošnik DTO je lahko vgrajen v .NET / C # / Java ali celo JavaScript / TypeScript. DTO je pogosto serializiran, tako da je lahko neodvisen od tehnologije, ki se uporablja v sprejemniku. V večini primerov prejemniku podatkov po prejemu ni treba spreminjati teh podatkov - v idealnem primeru ne bi smel!

To je klasičen primer pomena nespremenljivosti. In ravno zato bi moral biti DTO nespremenljiv!

Obstaja več načinov, na katere lahko v C # uporabite nespremenljive DTO. Lahko uporabite ReadOnlyCollection ali nespremenljive vrste zbirk, ki so varne za nit, prisotne v imenskem prostoru System.Collections.Immutable. Vrste zapisov v C # 9 lahko izkoristite tudi za izvajanje nespremenljivih DTO-jev.

Oblika, zasnovana na domeni, pričakuje, da bodo predmeti domene zunanje nespremenljivi. To je dober razlog, da svoje DTO spremenite, kajne?

DTO serializacijski izzivi

Morali bi biti sposobni brezhibno serializirati / deserializirati DTO, da ga lahko prenesete po žici. V praksi pa boste morda morali pri delu z DTO rešiti nekatere težave s serializacijo. V resnični aplikaciji imate lahko več entitet ali razredov modelov in vsak od njih se lahko sklicuje drug na drugega.

Recimo, da ste zgradili sistem upravljanja prisotnosti za zaposlene v svoji organizaciji. Običajno imate v aplikaciji razred z imenom Employee, ki se sklicuje na razred User (tj. Employee je uporabnik aplikacije), ki se nato sklicuje na razred Role. Razred Vloga se lahko sklicuje na razred Dovoljenja, ta pa na razrede PermissionType in PermissionGroup. Zdaj, ko serializirate primerek razreda Employee, boste na koncu serirali tudi te predmete. Preprosto je videti, da lahko v nekaterih zapletenih primerih na koncu serializirate več vrst.

Tu priskoči na pomoč leno nalaganje ali asinhrono nalaganje. To je funkcija, ki vam lahko pomaga naložiti entitete le, ko vas to zahteva. Za več informacij o lenobnem nalaganju si lahko ogledate moj članek o leni inicializaciji v C #.

Predmeti za prenos podatkov običajno ne vsebujejo poslovne logike - vsebujejo samo podatke. Nespremenljivost je zaželena lastnost pri delu z DTO. Obstaja več načinov, na katere lahko uporabite nespremenljive DTO. Več o nespremenljivosti v C # bom obravnaval v kasnejšem prispevku tukaj.