WCF Web サービスでデータ コントラクトとして DTO を使用しています。これらの DTO の目的は、特定の API メソッドに関連する情報のみを公開することです。
私が皆さんに求めているのは、ここでのベスト プラクティスに関するアドバイスです。
たとえば、次の単純なモデルを考えてみましょう。
class Order
{
int CreatedBy { get; set; }
DateTime CreatedOn { get; set; }
string Description { get; set; }
int Id { get; set; }
string Name { get; set; }
}
私たちの API により、消費者は注文の作成、更新、および取得を行うことができると仮定して、次の DTO を作成しました。簡単にするために、DataMember および DataContract 属性は削除されています。
メソッドの作成: ユーザーはIdプロパティとCreatedOnプロパティを指定できないため、DTO は次のようになります。
class CreateOrderData
{
int CreatedBy { get; set; }
string Description { get; set; }
string Name { get; set; }
}
更新方法: ユーザーはId、CreatedOn、およびCreatedByプロパティを指定できないため、DTO は次のようになります。
class UpdateOrderData
{
string Description { get; set; }
string Name { get; set; }
}
Getメソッド: ユーザーは Order のすべてを表示できる必要があるため、DTO は次のようになります。
class OrderData
{
int CreatedBy { get; set; }
DateTime CreatedOn { get; set; }
string Description { get; set; }
int Id { get; set; }
string Name { get; set; }
}
だからここに私の質問があります:
Order モデルにさらにプロパティがあり、それらのプロパティの多くが「作成」DTO と「更新」DTO の間で共有されていると仮定すると、これらのクラスを共通の基本クラスから拡張することは理にかなっていますか? はいの場合、「Get」DTO (OrderData) もそのクラスから拡張する必要がありますか? それを行うと、これらの DTO が相互に依存しすぎませんか?
「作成」DTO と「更新」DTO の間ですべてのプロパティが共通している場合でも、2 つの異なる DTO を作成する必要がありますか? はいの場合、なぜですか? そうでない場合 (これは単なる命名の問題です)、名前が「Get」DTO とは明らかに異なるように、「CreateOrUpdate」DTO を何と呼ぶ必要がありますか?
すべての DTO に「Data」、「DataObject」、「Dto」などのサフィックスを付けても問題ありませんか?
私たちはここで正しい軌道に乗っていますか? そうでない場合、どうすればこのデザインをより良くすることができますか?
アップデート:
基本クラスも WSDL で公開され、クライアントがそれを確認してインスタンス化できるため、DTO での継承は好きではないと思います。 . 継承の代わりに共通のプロパティを適用するために、DTO でインターフェイスを使用するのはどうですか? DTO には何の動作も含まれていないはずなので、継承を置き換えることによって多くを失うことはありません。