Entity Frameworkを使用している場合、私はseveralの記事とquestionsの外部キーと独立した関係の概念について読んでいます。 そして、私はまだ100％どのような道に行くのかは確信していません.... 私はすでに "has to"というプロパティの参照を持っているときにFKの関係で使用されるプロパティを持つことによってドメインPOCOを "汚染"したくないです"オブジェクト。外部キーと独立したリレーションシップ - Entity Framework 5では改善がありますか？
私の質問は（あなた@EFTeam、@Ladislav Mrnkaを見て）されている
大きなモデルをお持ちの場合は、とにかくドメインオブジェクト（または一般的な概念モデル）を「汚染」する必要があります。 FKマッピングされた関連付けを持つモデルの場合、クエリを実行したり変更を保存したり、ビルド時に移動できる（「ビュー生成前」）ために必要なEF処理パイプラインのステージである「ビュー生成」のコストは独立した関連性を有するモデルと比較して低い。これは重要です。なぜなら、小さなモデルではそれを実行する時間が目に見えない可能性があるからです。特に、NULL可能な外部キーにマップされた関連付けがある場合は、非常に高速になります（-0.1または-1 TPHマップされた階層内）。公式EF5 performance considerations documentでは、非常に大きなモデルのビュー生成時間の例の違いは、「1ヶ月以上、次に諦めました」（独立した関連付けで）と104分（FKでマップされた関連付けで）の間で与えられます。私の場合（数百もの高度に接続されたエンティティ）、それは25分から40秒です。以前のバージョンと同じように、EF5でも状況は同じです。
改善はありません。両方のオプションが存在します。 FKアソシエーションを使用する利点は、切断されたオブジェクトグラフを使用して作業する場合に、一対多の関係の変更を簡単に処理できることです。また、データバインディングを使用する場合は、データバインドも簡素化する必要があります。
ドメインのPOCOの「汚染」を犠牲にして、FKの関係がより多くの利点を提供するように見えます。「使用するとデータバインディングも簡素化する必要がありますか」を詳しく説明できますか？それはどういう意味ですか？（私は「視覚的」な人ですか？）ありがとう – zam6ak
私はまた、非常に大きなモデル（75以上のエンティティ）を持っています。 FK関係の使用が推奨されるように見えますか？ – zam6ak
パフォーマンスの問題がまだ表示されていない場合（具体的には、最初の '.SaveChanges'で長時間待ってから、与えられたエンティティセットにアクセスする最初のクエリでわずかに遅れます）、クリーナーコードに依存しない関連が好きなら、FKを使う必要はありませんもっと与える。 – cynic