'ObjectContext'ではなく 'DbContext'を使用する方が良いでしょうか？

Question

EntityFramework.dll v4.3をダウンロードしました。私はDbContextとObjectContextを比較するいくつかの質問を見つけました。しかし、これらのほとんどは2010年、または2011年初めです。

私はこの件についてもっと詳しく知りたいと思います。具体的には、DbContextに関する書籍がありますか？私はまた、今日の時点で、DbContextの制限は何ですか、それを兄弟と比較するときに知りたいのは、ObjectContextですか？

DbContextは、より少ないプロパティを公開するという点でよりコンパクトです。これは、私がObjectContextから移行する必要があることを示唆しています。しかし、私がこの移行を行う場合、私は何か能力をあきらめますか？たとえば、私はDbContextにSTE（セルフトラッキングエンティティ）機能がないと読んでいます。これはまだ成立していますか？

Answer 1

私はこの件についてさらに詳しく知りたいと思います。具体的には、DbContextには の本がありますか？

Googleの1つのクエリから回答が得られるため、質問がうまく始まらない場合があります。 excellent book about DbContextそれ自体には—がありますが、コードファーストアプローチについては何も含まれていませんが、実際にはあなたの質問のポイントではないと思います。

私はDbContext対 ObjectContextを比較する質問の数を見つけました。これらのほとんどは2010年、または2011年初め

からあなただけのDbContext + EDMXとObjectContext + EDMXを交換したい場合でも、比較はまだ同じです。 DbContextは、ObjectContextのラッパーであり、その機能セットはコードの最初と移行に関連する機能を除いて成長しませんでした。

私は、DbContextがより少なくても のプロパティを公開するという点でよりコンパクトであることを認識しています。これは私が ObjectContextから移行する必要があることを示唆しています。

はい、よりコンパクトで、コンテキストに関連した最も一般的な作業が簡単になります。より複雑なタスクの場合は、DbContextインスタンスをIObjectContextAdapterを通じてObjectContextインスタンスに変換することができます。

ただし、この移行を行うと、どのような機能も放棄されますか？ の例では、DbContextにSTE（セルフトラッキング エンティティ）機能がないと読んだことがあります。これはまだ成立していますか？

STEはObjectContextのために作成されたと私はそれがDbContextに移植されたとは思わないが、あなたは、この機能を自分で実装しようとすることができます。

STEは単なる問題を解決するためのアイデアを持ったテンプレートです。それは良い理論的解決策として現われましたが、現実世界のシナリオでは解決策があまり良くないので、開発者コミュニティはこれをあまり受け入れていませんでした。また、テンプレートを改善または移植するのではなく、他のより重要な機能が開発されている理由もあります。