6

次のようなPOCOでEFコードを最初に使用する例がたくさんあります。

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public virtual Blog Blog { get; set; }
}

では、Blog物件をご覧ください。代わりに次のようにすべきではありません：

private Blog blog;
public virtual Blog Blog 
{ 
    get
    {
        return blog;
    } 
    set
    {
        blog = value;
        if (blog != null)
        {
            BlogId = blog.BlogId;
        }
    } 
}

つまり、すでにモデルを外部キーで「汚染」しているので、少なくとも参照と同期させておくべきではないでしょうか? または、とにかくデータを読み取るときに依存するべきではありません（たとえば、特定のものがリストにあるBlogIdかどうかを知りたい場合など）。BlogIdそれとも、DbContext(のようなKeepForeingKeysPropertiesSyncronizedWithReferences) に魔法のプロパティがあり、それが私にそれをもたらし、これについて心配している悲しいプログラマは私だけですか? それとも私は妄想的ですか？（また、私の下手な英語で申し訳ありません）

編集 申し訳ありませんが、これは本当にばかげた質問でした。Stefan の言うとおりです。EF は本当にあなたのためにこれを行います。渡していた参照が でロードされていたため、これは見られませんでしたAsNoTracking()。この状態でのみ、ID を持つ参照があり、外部キー フィールドは 0 になります。既にコンテキストにある参照を渡す限り、それは機能するはずです。

4

2 に答える 2

1

これ自体を行う必要はありません。EF がこれを行います。
独立した関連付けプロパティを設定すると、EF は外部キー プロパティを同期して変更を反映し、その逆も同様です。すぐに自動的に発生するわけではありませんが、これは SaveChanges を呼び出した後に発生すると思いますが、わかりません。
一部の人々が外部キー プロパティを使用する理由を知りたい場合は、Web アプリなどの分離型アプリの方が便利です。アプリをスケーリングする必要がある場合は、パフォーマンスの向上にも役立ちます (これは、最近の MS ブログのどこかの投稿で読んでください)。
基本的に、これを自分で行う必要があるのは、ミックス アンド マッチングを行う場合のみです。あるメソッドで独立関連プロパティを使用し、別のメソッドで外部キー プロパティを使用している場合。

于 2012-08-30T10:49:20.390 に答える