0

私が理解しているように(間違っている場合は訂正してください)、それらの間に関係を持つエンティティークラスはいくつかの方法で定義できます - (1) スカラーキーを表すプロパティとナビゲーションプロパティの両方を使用するか、(2 ) ナビゲーション プロパティを使用するだけです。

データ注釈を使用する場合、唯一の選択肢はスカラー キーとナビゲーション プロパティの両方を使用することですが、Fluent API を使用すると両方のアプローチが利用可能です。

私の質問は、どのアプローチをとるかです。それぞれの長所と短所は何ですか？(これは、外部キーとナビゲーション プロパティに関する 2 つの選択肢に関するものです...データ注釈と Fluent に関するものではありません。

私が見ているように、それはこれらの要因/懸念に要約されます

  1. スカラー プロパティとナビゲーション プロパティの両方を持つことは、クラスを "汚す" と見なすことができます。
  2. ナビゲーション プロパティだけを持つと、FK 値にアクセスするには、Includes() 呼び出しが必要になります。送信されている SELECT ステートメントは見ていませんが、JOIN が実行されており、不要なデータが返送されていると思われます。
  3. スカラー プロパティがあると、Include() 呼び出しの必要がなくなります。
  4. 私からの以前の SO の質問 (関連する質問) で示唆されているように、ナビゲーション プロパティを複合キーの一部として使用できないように見えるため、追加のスカラー キーを含める必要があります。また、1 つのプロパティに対してそれを行う必要がある場合は、すべてのクラスで一貫性を保つことが理にかなっています。

何か不足していますか？一般的に、外部キーとナビゲーション プロパティを定義する推奨される方法は何ですか? 混乱しているように見えるのに、なぜ両方のアプローチを提供するのでしょうか? 私は多くのチュートリアルを見てきましたが、両方のアプローチが混在していることがわかります。

ありがとうございました。

4

1 に答える 1

1

(1) スカラー キーを表すプロパティとナビゲーション プロパティの両方を使用する方法、または (2) ナビゲーション プロパティのみを使用する方法。

それが外部キーと独立した関連付けの違いです。

データ注釈を使用する場合、唯一の選択肢はスカラー キーとナビゲーション プロパティの両方を使用することですが、Fluent API を使用すると両方のアプローチが利用可能です。

いいえ。データ注釈は単なるヒントです。ナビゲーション プロパティは、既定の規則によって自動的に認識されます。

スカラー プロパティとナビゲーション プロパティの両方を持つことは、クラスを "汚す" と見なすことができます。

はい。ただし、スカラー プロパティを持つ 2 つの関連付けタイプの性質が異なるため、いくつかの開発タスクが簡単になります。

ナビゲーション プロパティだけを持つと、FK 値にアクセスするには、Includes() 呼び出しが必要になります。送信されている SELECT ステートメントは見ていませんが、JOIN が実行されており、不要なデータが返送されていると思われます。

はい。Includeはデータのフェッチを意味しますが、linq-to-entities クエリでのみ FK にアクセスする必要がある場合は使用する必要はありません。例：

 var children = from c in context.Children
                where c.Parent.Id == 123
                select c;

このクエリは「FK」を介してアクセスしParent、内部的に結合を生成しますが、親はフェッチしません。

スカラー プロパティがあると、Include() 呼び出しの必要がなくなります。

No.Includeはナビゲーション プロパティに依存し、FK プロパティ自体は関連付けを作成しません。リレーションの少なくとも一方の側に常にナビゲーション プロパティが必要です (ParentまたはChild私の例のいずれか)。

ナビゲーション プロパティを複合キーの一部として使用できないようです

はい。複合キーが必要な場合は、エンティティで外部キーを公開する必要があります。

追加の関連する質問があります。

于 2012-10-07T09:45:38.163 に答える