DbContextの説明には、「DbContextインスタンスは作業単位とリポジトリパターンの組み合わせを表しています...」です。しかし、多くの開発者は独自のリポジトリとUoWを作成する傾向があります。独自のUoW /リポジトリとDbContextを直接使用するかどうかの違い
DbContextとDbSetを直接使用するか、自分のリポジトリに保存する必要がありますか？違いは何ですか？
DbContextを直接使用すると問題はありますか？将来私はMS SQLからOracleに切り替えるのですか？
フォローMSDN
他の回、あなたの 永続ツールから作業のインナーユニットをラップ作業インタフェースやクラスのアプリケーション固有ユニット を書きたいことがあります。あなたはいくつかの理由でこれを行うかもしれません。 アプリケーション固有のロギング、トレース、またはエラー処理 をトランザクション管理に追加することができます。おそらく、 アプリケーションの残りの部分から持続ツールの詳細をカプセル化したいと思うかもしれません。 は、後で永続テクノロジをスワップアウトするために、この余分なカプセル化が必要な場合があります。あるいは、 があなたのシステムでテスト容易化を促進したいかもしれません。組み込みの作業単位 の多くは、一般的な永続性ツールからの実装では、自動ユニットテストのシナリオでは を扱うことが困難です。
ご質問にお戻りください。
私はDbContextとDbSetを直接使用する必要がありますか、それとも自分の リポジトリにする必要がありますか？
実際にはDbContextとDbSetをリポジトリに入れても問題ありません。私たちは自分でもっと簡単にはテストしたくないと頼んでいます。 DbContextとDbSetをそのままRepositoriesに使用しないでください。 DbContextを提供するために使用するインタフェースIDbContextFactoryを使用する必要があります。ちょうど私の2セントです。
リポジトリに関する多くのビューを得るために、以下のリンクを参照して、リポジトリとDbContextの間のオプションを検討することができます。私たちが直接DbContextを使用する場合
http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
何か問題はありますか？
いいえ、DbContextを直接使用すると問題はありません。しかし、データベースの集中化、テストの難しさ、設計原則の懸念とは別個の違反など、多くのビジネスルールと大規模な問題が厄介になります。
今後、MS SQLからOracleに切り替えるのはどうですか？
実際には、将来、MS SQLとOracleを切り替えるときに問題はありません。 Entity FrameworkのDbContextを使用する場合は、データプロバイダのみを変更してください。