実際のソフトウェア開発プロジェクトでは、多くの場合、「ビジネス ロジック」により、同じデータに対してさまざまな変換を実行する必要があります。たとえば、Web アプリケーションはフロントエンドを通じてユーザー入力を Dto に収集し、Dto をドメイン モデルに変換してデータベースに保存します。一方、ユーザーがデータを要求した場合は、その逆のことを行う必要があります。つまり、データベースからクエリされたドメイン モデルを逆の方法で Dto に変換し、ユーザーに提示する必要があります。場合によっては、複数のクライアントがデータを使用するなど、より多くのデータ使用要件に直面することもあります。そのため、より多くのデータ変換を実行する必要もあります。
頻繁なデータ変換は些細で面倒な作業です:
(1) 2 つのタイプは名前が異なるだけですが、ほぼ同様の構造を持っています。ただし、タイプ間のデータ転送は、属性 1 を手動で割り当てることによってのみ実現できます。 「伝達」によって。
(2) 新しいデータ変換シナリオが発生するたびに、一連の変換ロジックが手動で実装され、その結果、データ変換操作が繰り返され、アプリケーションの隅々に分散されます。
「オレンジ」を私たちが望む「リンゴ」に変えることができるそのような「トランスフォーマー」のようなツールがある場合、私たちがしなければならないことは、変換ルールを定義することだけです - 実際のビジネスロジックを実行するか、または単純なシナリオで実行するだけですルールを定義する必要はありません (設定よりも規約)、これは非常に美しいことです。実際、強力なオブジェクト間マッピング ツールである AutoMapper があるため、.NET で車輪を再発明する必要はありません。
実際、私が取り組んでいるプロジェクトは上記の「混乱」を経験しているのですが、AutoMapper は本当に明るい気持ちをもたらしてくれます。そこで、週末のちょっとした休暇を利用して AutoMapper を試してみたところ、小さなアプリケーション シナリオを通じて Dto とドメイン モデルのマッピングを実現し、その「強力なオーラ」を実感しました。同じように混乱しているあなたの助けになればと思い、この記事で私の使用経験を共有します。完全なプロジェクト コードは後で私の git リポジトリにリリースしますので、どなたでも自由に参照していただけます。
【1】アプリケーションシナリオの説明
まず、「仮想」ドメインモデルを見てみましょう。今回は本屋 (BookStore) を定義しました:
パブリック アドレス アドレス {get; set;} }
書店には独自のアドレス (アドレス) があります:
C# コード public クラス Address
{
public string City { get; }
public string PostCode { get; }書店で:
C# コード
{
パブリック文字列 説明 { 取得; }
public 10 進数 { get; set; }
public DateTime { get; set; public int { get; set;
}
各書籍には出版社情報があります:
}
各書籍には最大 2 つの著者情報 (著者) を含めることができます:C# コード
public class Author
{
public string Name { get; set;
public string description { get; set; }
public ContactInfo ContactInfo { get; }
}
C# コード
Dto 構造をもう一度見てみましょう。
Dto には BookStore に対応する BookStoreDto があります: public class BookStoreDto { public Listパブリッククラス BookDto
{
パブリック文字列 { 取得; セット; }
パブリック 10 進数
public DateTime { get; set; }
public string FirstAuthorName { get; } FirstAuthorDescription { 取得; }
パブリック文字列 FirstAuthorBlog { 取得; }
パブリック文字列 SecondAuthorDescription { 取得; }
パブリック文字列 SecondAuthorTwitter { 取得; }
Dto から Model へのマッピング ルールを見てみましょう。
(1) BookStoreDto -> BookStore のフィールドBookStoreDto フィールド
Name Name
Books Books
Address Address
(2)AddressDto -> Address
フィールド住所のDtoフィールド
国
都市
都市
通り
郵便番号
(3) BookDto -> Book。
BookDto の一部の基本フィールドは Book のフィールドに直接対応できます。
Book のフィールドDto Book のフィールド
Title タイトル
Description 説明
Language 言語
Price 価格
Pub lishDate PublishDate
Paperback ペーパーバック
各書籍には次の場所がありますBookDto の著者のほとんど 2 名 フィールドで表されるそれぞれ「First」と「Second」という接頭辞が付きます。したがって、すべての FirstXXX フィールドは Book の Authors の最初の Author オブジェクトにマップされ、すべての SecondXXX フィールドは Authors の 2 番目の Author オブジェクトにマップされます。
BookDto のフィールド BookDto の著者の 1st Author オブジェクトのフィールド
FirstAuthorName 名前
FirstAuthorDescription 説明
FirstAuthorEmail ContactInfo.Email
FirstAuthorBlog ContactInfo.Blog
FirstAuthorTwitter ContactInfo.Twitter
ContactInfo.Email に注意してください上の表の は、Author オブジェクトの ContactInfo に対応する Email フィールドを表します。同様に、次のようになります。
BookDto のフィールド Authors in Book の 2 番目の Author オブジェクトのフィールド
SecondAuthorName Name
SecondAuthorDescription 説明
SecondAuthorEmail ContactIn fo.Email
SecondAuthorBlog ContactInfo.Blog
SecondAuthorTwitter連絡先情報 .Twitter
最後に、Publisher フィールドがあります。これは、独立した Publisher オブジェクトに対応します。
出版社の BookDto フィールド
出版社名
必要なのは、この大きな Dto から別の大きなモデルにデータを変換することです。