1

Bar 型のプロパティを持つ Foo があるとします。両方とも、ID で取得できるデータベースに永続化されます。(ID は実際には顧客サービス要求によって基幹業務で使用されます。したがって、それらは単なるインデックス プレースホルダーではありません。) b1 または b2 で示したアプローチを取ることができます。

エンティティを連鎖させると怖くなります。これをやりすぎると、簡単に Null がポップアップしてしまうからです。一方で、ID をどこにでも表示することは、不要な言葉遣いを追加しているように見えます。

int fooKey = 123;
Foo f = new Foo(fooKey);
Bar b1 = new Bar(Foo.BarID);  //This?
Bar b2 = Foo.Bar;  // Or This?

注: これは .NET エンティティ フレームワークに関するものではありません。実体という言葉は、ここでは一般的な意味で使用されています。

4

2 に答える 2

1

通常、不必要な密結合が発生するため、連鎖を避けるようにしています。すべてはコンテキストに依存しますが、ビジネス オブジェクトに関しては、エンティティを疎結合にして、独立して成長できるようにすることをお勧めします。

あなたが提供する例では、密結合が保証されているとは思いません。交差が大きければ、これは保証されるかもしれませんが、これはビジネス エンティティの一般的なケースではないことがわかりました。

于 2009-02-02T23:09:16.297 に答える
0

MSFT が LINQ to SQL を実装した方法を見てみましょう。どちらかまたは両方を設定できます。彼らのマッパーは、必要に応じてプロパティと遅延ロードの両方を公開するほどスマートです。IMO、最も単純な方法 (ID を使用) を使用するか、空想が必要な場合は、Hibernate/NHibernate、Linq to SQL、Linq to Entities などの O/R マッパーを使用する必要があります。

于 2009-02-02T22:51:12.170 に答える