4

データベース内の従業員レコードを表すEmployeeDTOがあります。Employeeテーブルには、Departmentとの関係、およびPermissionとの1対多の関係があります。

私のエンティティでは、これらは完全に拡張されたDepartmentプロパティと完全に拡張されたアクセス許可オブジェクトのリストとして表されます。

問題は、DTOにDepartmentIdの完全に拡張されたDepartmentDTOプロパティを含める必要があるかどうかです。DTOには、List of PermissionIdの完全に拡張されたPermissionDTOプロパティのリストが必要ですか？

4

2 に答える 2

3

デザインのすべてのように、それはあなたのニーズに依存します。

  • 子プロパティを頻繁に表示してバインドする必要があり、開発者がDTOをできるだけ簡単に使用できるようにしたい場合は、完全に拡張された子プロパティを提供する明示的なファクトリメソッドが必要になる場合があります。
  • コードを単純にしたい場合は、外部キープロパティを展開せず、開発者が必要に応じてキーごとに必要な子オブジェクト/コレクションを取得できるようにします。

再帰で問題が発生する可能性があります。また、Departmentオブジェクトのすべての外部キープロパティも展開しますか？Departmentのサブクラスに別のEmployeeDTOへの参照がある場合はどうなりますか？

MicrosoftのEntityFramework、およびその他の一般的なビジネスオブジェクトフレームワークは、遅延読み込みによってこの概念を処理します。コードで要求された場合にのみ、完全に拡張された子プロパティをフェッチします。これはおそらく最も柔軟なソリューションですが、親オブジェクトと同じデータベース呼び出しで子プロパティをフェッチできないため、オーバーヘッド/ラグが少しあります。もちろん、これらは純粋なDTOではありません。

于 2011-03-22T13:41:44.257 に答える
2

はい、いいえ。これは、通話と、すべての通話ですべての追加プロパティが必要かどうかによって異なります。また、使用するORMテクノロジに依存する可能性があります。これは、遅延読み込みを実装でき、決定に影響を与える可能性があります（推奨されていませんが、ストレートエンティティオブジェクトを渡す場合）。

必要なすべてのプロパティを含む1つのケースDTOと、より多くの機能を公開し、他のメソッドで使用される1つ以上のDTOオブジェクトを作成するのが一般的です。たとえば、私にはとBasicUserだけを含むクラスがあり、`BasicUserからより多くのインクルードと継承を含むクラスがあります。UserNameDisplayNameUserPermissions

于 2011-03-22T13:39:39.763 に答える