私はDTOを使用して最初のアプリケーションを構築しています-現在、特定のオブジェクトのデータを取得するための1つのDTOと、データを更新(PUTting)するための別のDTOがあります-クライアントから更新できるフィールドはごくわずかであるため、私は決定しました不要なデータ/フィールドをネットワーク経由で送信しないように、PUTting専用のDTOを作成します。これは保守性の観点からは良い習慣ですか、それともある種のノーノーですか?
4 に答える
同じタイプを複数の操作に使用しても問題ありません。おそらく、同様の目的で同様のデータを返す複数のGETがあります。そのシナリオで同じタイプを再利用できない理由はありません。
ただし、GET操作とPUT操作には異なるデータが必要であることがわかりました。したがって、それらは異なる操作であるだけでなく、異なるデータも必要とします。
+----------------+-------------------+--------------------------+
| Similar Data | Similar Purpose | Try to Reuse |
| Similar Data | Different Purpose | Consider; is it logical? |
| Different Data | Similar Purpose | New Type |
| Different Data | Different Purpose | New Type |
+----------------+-------------------+--------------------------+
特定のニーズを満たすために新しいDTOを作成することには、次のような他の利点があります。
- 開発者を混乱させないでください(たとえそれがあなただとしても!)
- 使用を意図していないフィールドが入力されるセキュリティホールを開かない
簡単にするには:
- インターフェイスを使用して、タイプ間で共通のフィールドを適用できます。
- ASP.Net Web API(質問から使用しているかどうかはわかりません)は、動的入力を強力にサポートしています。これにより、DTOが不要になります(ただし、コンパイル時の型チェックが少なくなります)。
それは選択の問題です。私はコードを減らすためにormマッパーを使用する習慣があります。事前に時間をかけて保存を定義し、1つのdtoクラスで作業することで、すべてのフィールドが更新されることを意味する場合でも、スケーラビリティと保守性が向上することがわかりました。エッジケースがあります。テーブルがblobタイプのデータの大きなゴブを持つフィールドを使用する場合は、これらの更新を何らかの方法でサブクラス化する必要があります。それは意見の問題です。
エンティティごとに複数のDTOを使用します。ただし、ビューの事前定義されたDTOさえ持っていないことがよくあります。Linqを使用してエンティティからの投影である匿名クラスインスタンスを作成し、それをGUIにバインドします。
例:ユーザーのリストを表示する
var users = ... // fetch from DB
ViewData["users"] = users.Select( u => new { Id = u.Id, Name = u.First + " " + u.Last});
スコアボードの表示:
var users = ... // fetch from DB
ViewData["users"] = users.Select( u => new { Id = u.Id, Name = u.Last, Score = u.Score});
これにより、2つの異なるDTOを作成する必要がなくなります。潜在的な欠点は、ビューが強く型付けされていないことです。そのため、ASP.NET MVCのバージョンによっては、ビューモデルを宣言するか、dynamic
いくつかのトリックを使用する必要がありますExpandoObject
が、すべてうまく隠されています。
ただし、私は常に状態を変更するためのDTOを作成し、それらをコマンドとして扱います。私は通常、エンティティの操作ごとに異なるDTOを持っています。たとえばChangeUserAddressDTO
、ChangeUserLevelDTO
などです。
いいえ、いいえではありませんが、CRUDに同じDTOを使用すると、長期的にはより保守しやすくなります。後で、新しいフィールドが追加および削除された場合、すべてのレイヤーのコードを変更しなければならない場合があります。クライアントが多かれ少なかれデータを編集することに気が変わったとき、あなたは決して知りません。