1

AutoMapper（双方向マッピングの賛成/反対の議論）に関してLosTechiesについて非常に興味深い議論がありました。

私が現在取り組んでいる問題のために、これは実際に私の注意を引きました。料金や配達時間などの情報をユーザーに提供するために、出荷品に取り組んでいます。実際のサービスを一元化するために、ドメインエンティティを永続化するWCFWebサービスがあります。

ドメインモデルを単純化するために、基本的に2つのクラスがあります。

public class Shipment
{
 public IList<Item> Items{get;set;}
}

public class Item
{
 //some primitive properties
}

また、ワイヤ全体の負荷を軽減するために作成された、対応するDTOのセットもあります。プレゼンテーションピース（またはWebサービスに関係するピース）は、ドメインモデルの知識がなくてもDTOを使用します。

私の質問はここにあります。貨物を作成するために、サービスはアイテムのリストを受け入れます。出荷を作成するためのロジックがあり、それはすべてWebサービスの背後に隠されています。本質的に、これはItemDTOがネットワークを介して渡され（クライアント->サーバー）、出荷が作成され、次にShipmentDTOが返される（サーバー->クライアント）ことを意味します。現在、ShipmentDTOにはItemDTOの子リストもあり、これにより双方向マッピングシナリオが作成されます。

これは単純なCRUD操作以上のものであり、コマンドメッセージパターンにかなり慣れていないので、コミュニティがこの問題をどのように解決するのか興味があります。

2ウェイマッピングでDTOを双方向に渡しますか？

使用例（プレゼンテーション層）：

List<ItemDTO> list = new List<ItemDTO>();
//add items to list


ShipmentServiceClient client = new ShipmentServiceClient();
List<ShipmentDTO> shipments = client.GetShipments(list);

//shipments are now displayed to the user
//with respective costs and other useful data
4

2 に答える 2

1

その投稿で私がよく理解していなかったのは、返答の言葉遣いでした。「着信DTOはコマンドメッセージにマップされます」。つまり、DTOは双方向にすることができ、提供されるマッピング（AutoMapper）は単方向です。

于 2009-11-10T15:27:26.393 に答える
0

質問の要点を見逃すリスクがありますが、間違った理由でDTOを再利用しない限り、双方向でDTOを使用しても問題ありません。あなたの場合、サーバーが各ItemDTOに完全に入力された一連のアイテムの出荷を作成するようにサーバーに要求しているので、サーバーがそれを取り戻したときに、ItemDTOは基本的に同じですか？または、実際に複数のアイテムの発送をリクエストしていますが、戻ってきたItemDTOには、サーバーによって入力された追加の詳細（アイテムごとの送料、在庫状況など）がありますか？後者の場合、ItemDTOを再利用して、出荷が要求されている特定のアイテムと、アイテムに関する出荷の詳細の両方を表すことはできません。

于 2009-11-09T20:14:55.143 に答える