In tatsächlichen Softwareentwicklungsprojekten erfordert unsere „Geschäftslogik“ oft, dass wir verschiedene Transformationen an denselben Daten durchführen. Beispielsweise sammelt eine Webanwendung Benutzereingaben über das Frontend in Dto, wandelt das Dto dann in ein Domänenmodell um und speichert es in der Datenbank. Wenn der Benutzer andererseits Daten anfordert, müssen wir das Gegenteil tun: das aus der Datenbank abgefragte Domänenmodell auf die entgegengesetzte Weise in Dto konvertieren und es dann dem Benutzer präsentieren. Manchmal werden wir auch mit höheren Datennutzungsanforderungen konfrontiert, beispielsweise wenn mehrere Clients Daten verwenden. Jeder Client hat seine eigenen unterschiedlichen Anforderungen an die Datenstruktur, was auch erfordert, dass wir mehr Datenkonvertierungen durchführen.
Häufige Datenkonvertierung ist trivial und chaotisch:
(1) Die beiden Typen unterscheiden sich fast nur im Namen, sind aber in der Struktur ungefähr ähnlich, können aber nur durch manuelle Zuweisung von Attributen realisiert werden um eins. Die „Weitergabe“ von Daten zwischen Typen.
(2) Jedes Mal, wenn ein neues Datenkonvertierungsszenario auftritt, wird eine Reihe von Konvertierungslogiken manuell implementiert, was zu wiederholten Datenkonvertierungsvorgängen führt, die in alle Ecken der Anwendung verstreut sind.
Wenn es ein solches „Transformers“-Tool gäbe, das „Orangen“ in die „Äpfel“ verwandeln könnte, die wir wollen, müssten wir nur die Konvertierungsregeln definieren – unsere eigentliche Geschäftslogik ausführen oder sogar in einfachen Szenarien dort Es ist nicht nötig, Regeln zu definieren (Konvention statt Konfiguration), was eine sehr schöne Sache wäre. Tatsächlich müssen wir das Rad in .NET nicht neu erfinden, da wir über AutoMapper verfügen, ein leistungsstarkes Objekt-Objekt-Zuordnungstool.
Okay, ich gebe zu, dass ich ein wenig aufgeregt bin. Tatsächlich erlebt das Projekt, an dem ich arbeite, die oben genannte „Verwirrung“, und AutoMapper gibt mir wirklich ein helles Gefühl. Deshalb verbrachte ich eine kleine Wochenendpause, um AutoMapper auszuprobieren. Ich erkannte die Zuordnung von Dto zu Domänenmodellen anhand kleiner Anwendungsszenarien und spürte wirklich seine „leistungsstarke Aura“. Ich werde meine Erfahrungen bei der Verwendung in dem Artikel mitteilen und hoffe, Ihnen, die ebenfalls verwirrt sind, etwas Hilfe zu bringen. Ich werde den vollständigen Projektcode später in meinem Git-Repository veröffentlichen. Jeder kann gerne darauf zugreifen.
【1】Beschreibung des Anwendungsszenarios
Werfen wir zunächst einen Blick auf unser „virtuelles“ Domänenmodell. Dieses Mal habe ich einen Buchladen (BookStore) definiert:
C#-Code
public class BookStore
{
public string Name { get; ; }
public List >Die Buchhandlung hat eine eigene Adresse (Adresse):
C#-Code
öffentliche Klasse Adresse
{
öffentliche Zeichenfolge Land { get; set; }
public string City { set; }
public string PostCode { get; >
}
Gleichzeitig gibt es n Bücher (Bücher) im Buchladen:
C#-Code
öffentliche Klasse Buch
{
public string Title { get; }
public string Language { get; ; }
public decimal Price { get;Author> }
public Publisher Publisher { get; }
public int? Paperback { get; wird veröffentlicht Geschäftsinformationen (Herausgeber):
C#-Code
öffentliche Klasse Herausgeber
{
öffentlicher String Name { get;
}
Jedes Buch kann bis zu 2 Autoreninformationen (Autor) haben:
C#-Code
Autor der öffentlichen Klasse
{
public string Name { get;
public string Beschreibung { get; }
public ContactInfo ContactInfo { get; Kontaktinformationen (ContactInfo):
C#-Code
public class ContactInfo
{
public string Email { get; >
public string Blog { get; set }
public string Twitter { get; }
Das ist es, ein Domain-Modell mit hierarchischer Struktur.
Werfen wir noch einmal einen Blick auf unsere Dto-Struktur.
In Dto haben wir BookStoreDto entsprechend BookStore:
C#-Code
public class BookStoreDto
{
public string Name { get ; set; }
public List
, das den AddressDto enthält, der Address entspricht:
C#-Code
public class AddressDto
{
public string Country { get; set; }
public string City { set; }
public string PostCode { get; >
}
und BookDto entsprechend Book:
C#-Code
öffentliche Klasse BookDto
{
public string Title { get; }
public string Language { get; Preis { get; }
public DateTime? PublishDate { get; ; set; }
public string FirstAuthorDescription { get; 🎜>
public string FirstAuthorBlog { get; >
public string FirstAuthorTwitter { get; public string SecondAuthorDescription { get; ; set; }
}
Beachten Sie, dass unser BookDto die gesamte Buchhierarchie „abflacht“.
Es ist Zeit für uns, einen Blick auf die Zuordnungsregeln von Dto zu Model zu werfen.
(1)BookStoreDto -> BookStore
Felder in BookStoreDto Felder in BookStore
Name Name Name
Bücher Bücher
Adresse Adresse
(2) AddressDto -> Adresse
Felder in AddressDto Felder in Adresse
Land Land
Stadt Stadt
Straße Straße
Postleitzahl PLZ
(3) BookDto ->
Einige grundlegende Felder in BookDto können direkt Feldern in Book entsprechen.
Felder in BookDto Felder in Buch
Titel Titel
Beschreibung Beschreibung
Sprache Sprache
P Reispreis
PublishDate PublishDate
Paperback Paperback
Jedes Buch hat höchstens 2 Autoren. In BookDto werden Felder mit dem Präfix „First“ bzw. „Second“ verwendet. Daher werden alle FirstXXX-Felder dem ersten Author-Objekt in Book's Authors zugeordnet, und alle SecondXXX-Felder werden dem zweiten Author-Objekt in Authors zugeordnet.
Felder in BookDto Felder im 1. Autor-Objekt in „Autoren im Buch“
FirstAuthorName Name
FirstAuthorDescription Beschreibung
FirstAuthorEmail ContactInfo.Email
FirstAuthorBlog ContactInfo.Blog
FirstAuthorTwitter ContactInfo.Twitter
Beachten Sie, dass ContactInfo.Email in der obigen Tabelle die E-Mail darstellt, die der ContactInfo des Author-Objekts Field entspricht, und bald. Ebenso haben wir:
Felder in BookDto-Feldern im zweiten Author-Objekt in Authors in Book
SecondAuthorName Name
SecondAuthorDescription Description
SecondAuthorEmail ContactInfo .Email
SecondAuthorBlog ContactInfo.Blog
SecondAuthorTwitter ContactInfo.Twitter
Schließlich gibt es das Feld „Publisher“, das einem unabhängigen Publisher-Objekt entspricht.
Felder in BookDto-Feldern in Publisher
Publisher-Name
Das ist es, unser Bedarf besteht darin, diese große Dto-Datenkonvertierung zwischen einem anderen großen Modell zu realisieren.
