Jak používat objekty přenosu dat v ASP.NET Core 3.1

Objekt přenosu dat (běžně známý jako DTO) je obvykle instancí třídy POCO (obyčejný starý objekt CLR) používané jako kontejner k zapouzdření dat a jejich předání z jedné vrstvy aplikace do jiné. Obvykle byste našli DTO používané ve vrstvě služeb k vrácení dat zpět do vrstvy prezentace. Největší výhodou použití DTO je oddělení klientů od vašich interních datových struktur.

Tento článek pojednává o tom, proč bychom měli používat Objekty přenosu dat a jak s nimi můžeme pracovat v ASP.NET Core 3.1. Chcete-li pracovat s příklady kódu uvedenými v tomto článku, měli byste mít ve svém systému nainstalovanou Visual Studio 2019. Pokud ještě nemáte kopii, můžete si stáhnout Visual Studio 2019 zde.

Vytvořte projekt API ASP.NET Core 3.1

Nejprve si vytvořme projekt ASP.NET Core v sadě Visual Studio. Za předpokladu, že je ve vašem systému nainstalovaná Visual Studio 2019, vytvořte nový projekt rozhraní API ASP.NET Core v sadě Visual Studio podle pokynů uvedených níže.

Spusťte Visual Studio IDE.
Klikněte na „Vytvořit nový projekt“.
V okně „Vytvořit nový projekt“ vyberte ze seznamu zobrazených šablon „Webová aplikace ASP.NET Core“.
Klikněte na Další.
V okně „Konfigurace nového projektu“ zadejte název a umístění nového projektu.
Klikněte na Vytvořit.
V dalším okně „Vytvořit novou webovou aplikaci ASP.NET Core“ vyberte z rozevíracího seznamu v horní části .NET Core jako modul runtime a ASP.NET Core 3.1 (nebo novější).
Vyberte „API“ jako šablonu projektu a vytvořte novou aplikaci API ASP.NET Core.
Ujistěte se, že políčka „Povolit podporu Dockeru“ a „Konfigurovat pro HTTPS“ nejsou zaškrtnuta, protože zde tyto funkce nebudeme používat.
Ujistěte se, že je ověřování nastaveno na „Žádné ověřování“, protože také nebudeme používat ověřování.
Klikněte na Vytvořit.

Tím se vytvoří nový projekt rozhraní API ASP.NET Core v sadě Visual Studio. Tento projekt použijeme pro práci s objekty přenosu dat v následujících částech tohoto článku.

Proč používat objekty pro přenos dat (DTO)?

Pokud při navrhování a vývoji aplikace používáte modely k předávání dat mezi vrstvami a odesílání dat zpět do prezentační vrstvy, vystavujete vnitřní datové struktury vaší aplikace. To je hlavní designová chyba ve vaší aplikaci.

Odpojením vrstev vám DTO usnadní život při implementaci API, aplikací MVC a také vzorů zpráv, jako je Message Broker. DTO je skvělou volbou, pokud chcete předat lehký předmět po drátu - zvláště když předáváte svůj objekt médiem s omezenou šířkou pásma.

Pro abstrakci použijte DTO

Můžete využít výhod DTO k abstrahování doménových objektů vaší aplikace z uživatelského rozhraní nebo prezentační vrstvy. Přitom je prezentační vrstva vaší aplikace oddělena od servisní vrstvy. Pokud tedy chcete změnit prezentační vrstvu, můžete to udělat snadno, zatímco aplikace bude i nadále pracovat s existující doménovou vrstvou. Podobně můžete změnit doménovou vrstvu vaší aplikace, aniž byste museli měnit prezentační vrstvu aplikace.

Pro skrytí dat použijte DTO

Dalším důvodem, proč byste chtěli použít DTO, je skrývání dat. To znamená, že pomocí DTO můžete vrátit pouze požadovaná data. Jako příklad předpokládejme, že máte metodu s názvem GetAllEmployees (), která vrací všechna data týkající se všech zaměstnanců. Ilustrujme to napsáním nějakého kódu.

V projektu, který jsme vytvořili dříve, vytvořte nový soubor s názvem Employee.cs. Napište následující kód do tohoto souboru a definujte modelovou třídu s názvem Zaměstnanec.

veřejná třída Zaměstnanec
    {
  public int Id {get; soubor; }
  public string FirstName {get; soubor; }
  veřejný řetězec Příjmení {get; soubor; }
  public string DepartmentName {get; soubor; }
  public decimal Basic {get; soubor; }
  veřejné desetinné číslo DA {get; soubor; }
  public decimal HRA {get; soubor; }
  public decimal NetSalary {get; soubor; }
    }

Všimněte si, že třída Employee obsahuje vlastnosti včetně Id, FirstName, LastName, Department, Basic, DA, HRA a NetSalary. Prezentační vrstva však může potřebovat pouze Id, FirstName, LastName a Department Name zaměstnanců z metody GetAllEmployees (). Pokud tato metoda vrátí seznam, pak by kdokoli mohl zobrazit podrobnosti o platu zaměstnance. To nechcete.

Abyste se tomuto problému vyhnuli, můžete navrhnout třídu DTO s názvem EmployeeDTO, která bude obsahovat pouze požadované vlastnosti (například Id, FirstName, LastName a Department Name).

Vytvořte třídu DTO v C #

Chcete-li toho dosáhnout, vytvořte soubor s názvem EmployeeDTO.cs a zapište tam následující kód.

veřejná třída EmployeeDTO
    {
        public int Id {get; soubor; }
        public string FirstName {get; soubor; }
        veřejný řetězec Příjmení {get; soubor; }
        public string DepartmentName {get; soubor; }
    }

Nyní, když jsou k dispozici třídy objektů modelu a přenosu dat, můžete vytvořit třídu převaděče, která obsahuje dvě metody: jednu pro převod instance třídy modelu Zaměstnanec na instanci EmployeeDTO a (naopak) jednu pro převod instance of EmployeeDTO to an instance of the Employee model class. K mapování těchto dvou odlišných typů můžete také využít AutoMapper, populární knihovnu mapování mezi objekty. Více o AutoMapperu si můžete přečíst zde.

Měli byste vytvořit seznam ve servisní vrstvě vaší aplikace a vrátit kolekci zpět do prezentační vrstvy.

Nezměnitelnost DTO

DTO je určen k přenosu dat z jedné vrstvy aplikace do jiné vrstvy. Spotřebitel DTO může být postaven v .NET / C # / Java nebo dokonce v JavaScriptu / TypeScript. DTO je často serializován, aby mohl být nezávislý na technologii použité v přijímači. Ve většině případů příjemce dat nemusí tato data po přijetí upravovat - v ideálním případě by to nemělo!

Toto je klasický příklad důležitosti neměnnosti. A právě proto by měl být DTO neměnný!

Existuje několik způsobů, jak můžete implementovat neměnné DTO v C #. Můžete použít ReadOnlyCollection nebo neměnné typy kolekcí bezpečné pro vlákna přítomné v oboru názvů System.Collections.Immutable. Můžete využít výhod typů záznamů v C # 9 a implementovat také neměnné DTO.

Návrh založený na doméně očekává, že objekty domény budou externě neměnné. To je dobrý důvod, aby se vaše DTO neměnily, že?

Problémy se serializací DTO

Měli byste být schopni serializovat / deserializovat DTO bez problémů, aby jej bylo možné předat dál. V praxi však možná budete muset při práci s DTO vyřešit některé problémy se serializací. V aplikaci v reálném světě můžete mít několik entit nebo tříd modelů a každá z nich může obsahovat odkazy na sebe navzájem.

Řekněme, že jste vytvořili systém správy docházky pro zaměstnance ve vaší organizaci. Obvykle můžete ve své aplikaci mít třídu nazvanou Zaměstnanec, která odkazuje na třídu User (tj. Zaměstnanec je uživatel aplikace), která zase odkazuje na třídu Role. Třída Role může odkazovat na třídu Permission, která zase může odkazovat na třídy PermissionType a PermissionGroup. Nyní, když serializujete instanci třídy Employee, skončíte také se serializací těchto objektů. Je snadné si uvědomit, že v některých komplikovaných případech můžete skončit serializací několika typů.

Tady přichází na pomoc líné načítání nebo asynchronní načítání. Toto je funkce, která vám může pomoci načíst entity, pouze když budete požádáni. Další informace o tom, jak provádět líné načítání, najdete v mém článku o líné inicializaci v C #.

Objekty pro přenos dat obvykle neobsahují žádnou obchodní logiku - obsahují pouze data. Při práci s DTO je požadovaná funkce neměnnost. Existuje několik způsobů, jak můžete implementovat neměnné DTO. Více o neměnnosti v C # se budu zabývat v pozdějším příspěvku zde.