DTOの使用 - ガイダンス

Question

ガイダンスをお探しですか？

私は、バックエンドサービスとしてWCFを備えたSL4アプリケーションを構築しています。私のWCFサービス層はドメインモデル上にあり、私はドメインエンティティを、アセンブラを使って画面固有のDTOに変換しています。

私はユーザーとユーザーがグループに属していることを示す画面（セキュリティ関連）を持っています。そのユーザーは後でユーザーのグループを追加して削除してから、適用ボタンを押すことができます。この適用ボタンがヒットした場合にのみ、変更が提出されます。

現在、私はUserDetailDtoを持っています。このUserDetailDtoは、クライアントに送信されて画面に表示され、私の意図は、UserDetailUpdateDtoをサーバーに送ってドメインモデルへの実際の更新を実行するためです。

これは問題ありませんか？

もしそうなら、ユーザが私のUserDetailUpdateDが変更を送り返すべきであるかどうか、つまりクライアントサイドを変更しているとき、何が追加され、何が削除されました。

わかりませんが、ガイダンスは素晴らしいでしょう。

Answer 1

要件と展開環境についてはあまり知られていない場合、ガイダンスは常に厄介です。しかし、あなたのアプローチは私には合理的だと思います。

1）あなたはあなたのドメインエンティティとは別にDTOを保持しています。小さなシンプルなアプリケーションでは、ワイヤを介してエンティティを送信することは問題ありませんが、複雑さと機能が向上するにつれて、エンティティを互いにやりとりすることができます。

2）Queryオブジェクト（UserDetailDto）とCommandオブジェクト（UserDetailUpdateDto）を区別しています。この2つは、1つのオブジェクトを使用して満足させることもできますが、オブジェクトが2つのマスタを処理しているために複雑さ/機能が増すにつれて膨らみます（Queryオブジェクトはクライアントで消費され、Commandオブジェクトはサーバー）。すべてのコマンドDTOが動詞（たとえばUpdateUserDetail）で始まり、クライアント側の 'メソッド'から 'データ'を簡単に並べ替えることができます。

複雑な画面ロジックを使用してSLアプリケーションが大きくなる可能性が高い場合は、Model-View-ViewModel（MVVM）パターンを調べる価値があります。これにより、画面のデザインを画面の機能から切り離すことができます。開発チームの周りに作業を配布する際の柔軟性が少し向上し、単体テストのサポートが強化されます。

UpdateUserDetailオブジェクトに返される内容は、ドメインモデル（またはドメインモデル上に置かれているWCFサービス）で作業するのが最も簡単なものになるはずです。一般的には、DTOに関しては小さい方が良いです。