ForeignKey-ID を設定して以前のエンティティに外部キー エンティティを追加すると、関連付けられたオブジェクトが null になります。
これを説明しましょう：
前の手順で、AddressIdプロパティを に設定し、28を呼び出してエンティティ コンテキストを保存しましたcontext.SaveChanges()。
さて、なぜAddressId塗りつぶされますがAddress、NavigationProperty (テーブル whereのAddressオブジェクトである必要があります) としては?AddressAddress.Id == 28null
Entity Frameworks (EF) は、これを仕様で動作させます。外部キーを更新しても、ナビゲーション プロパティは更新されません。
ただし、ナビゲーション プロパティを更新すると、キーが更新されます。また、この場合、Addressエンティティは同じコンテキストから取得する必要があることに注意してください。そうでない場合は.SaveChanges()、エンティティを新しいものと見なし Address、データベースに追加しようとします。
どちらの方法が優れているかという問題に関しては、まあ、それは依存しています!
- キーの更新は簡単で、データ転送オブジェクト (DTO) またはプレーン SQL を使用してずっと行ってきたことです。そのため、EF の初心者が把握して使用するのは簡単です。
- ナビゲーション プロパティを更新すると、オブジェクト ベースのデータ モデルが得られます。コードがすっきりして読みやすくなりました。ただし、コンテキストには細心の注意を払う必要があります。EF を少し個人的に使用した経験から、ナビゲーション プロパティを更新しようとすると、特にコンテキストがデータ アクセス層の背後に隠されている多層アーキテクチャでは、価値よりも複雑さが増すことがわかりました。
私の意見では、EF の最も重要な利点は、LINQ-to-Entities を使用したクエリ操作にあります。クエリのコンパイル時の構文チェックと厳密な型指定があります。複数のレベルの子を持つオブジェクト ベースの結果セットを簡単に作成でき、コードを追加することなくデータ バインドに対応できます。もう SQL を書くことはめったにありません。
エンティティを再作成してからリロードすることで、これを修正しました。これは機能しているようで、n:m 関係ナビゲーション プロパティを再取得します。変。