0

私のソリューションでは Entity Framework を使用し、EF モデルを DTO オブジェクトに変換して、UI レイヤーから上下に渡します。

しかし、設計上の問題があります。Person テーブルとテーブルがありPersonUnavailibilityます。人には、利用できない期間がある場合があります。

私のPersonDTOオブジェクトには、オブジェクトだけでなく、PersonEF モデルのすべてのプロパティがありList<PersonUnavailibilityDTO>ます。したがって、私が自分の人を取得すると、その人の利用できない期間も取得します。

しかし、私はオブジェクトPersonUnavailibilityDTOを持っているべきですか？PersonDTOオブジェクトを取得するとPersonUnavailibilityDTO、それがどの人物に関連しているかがわかりますか?

もしそうなら、私は循環参照を取得します。私のPersonUnavailibilityDTO'sPerson プロパティには、彼のすべての PersonUnavailibility 行のリストがあります...そして、それぞれに がありPersonDTO、それぞれに .... などのリストがあります。

この種のものに最適なデザインは何ですか？親オブジェクトに関連する子オブジェクトのみを含めますか?

つまり、 だけPersonDTOが のリストを持ち、 には?PersonUnavailibilityDTOsがありPersonUnavailibilityDTOません。PersonDTO

4

4 に答える 4

2

場合によります。

個人ビューから dto を表示し、利用不可は常に個人を介してアクセスされるため、ほとんどの場合、これは必要ありません。

しかし、逆にオブジェクトにアクセスする場合は、その人を利用不可に追加する必要があります。

Dto をできるだけ小さく最小限に抑えるようにしてください。

于 2013-07-02T06:18:45.753 に答える
0

一般的な推奨事項として、オブジェクト間の双方向の関係を避けることをお勧めします。

リスクは、オブジェクトが同期していないことです。つまり、オブジェクト A は B (または B のコレクション) を指しているが、B は A を指していません。通常、代わりに null 参照があります。それを防ぐには、関係の両端を常に同期させておく必要がありますが、これには代償が伴います。

ただし、オブジェクトが作成時に構成され、後で変更されることはなく、オブジェクト間の不一致のリスクが無効になるため、オブジェクトが不変である場合 (DTO の場合など)、この点は緩和されます。

Jeroen が指摘したようにPersonDTO -> PersonUnavailibilityDTO、逆の関係が必要であることが明確に証明されるまでは、可能な限り単純な解決策をお勧めします。

于 2013-07-02T09:09:32.237 に答える
0

考えられるアプローチの 1 つは、エンティティのすべての可能な組み合わせを運ぶ汎用複合 dto モデルを持つことです。

http://netpl.blogspot.com/2010/12/generic-dto-model-and-other-silverlight.html

厳密な構造を失うという代償を払って、再利用可能な構造を手に入れます。

于 2013-07-02T07:10:22.053 に答える
0

DTO からコレクションを削除し、代わりにコレクションを要求するサービス メソッドを追加することをお勧めします。

function GetUnavailable(PersonID, Options) as IEnumerable(of PersonUnavailabilityDTO)

こちらです

  1. 循環参照なし

  2. DTOは軽量になりがち

  3. 実際のコレクションは、データベースに直接適用される追加のフィルター、順序付け、またはページングできちんと指定できます

于 2016-02-06T12:51:12.573 に答える