の説明にDbContextは、「DbContext インスタンスは、作業単位とリポジトリ パターンの組み合わせを表します...」と書かれています。しかし、多くの開発者は独自のリポジトリと UoW を作成する傾向があります。
DbContext直接使用する必要がありDbSetますか、それとも自分のリポジトリを使用する必要がありますか? 違いは何ですか。
DbContextを直接使用しても問題はありませんか? 将来、MS SQL から Oracle に切り替えたらどうですか?
2549 次
1 に答える
5
MSDN に従う
また、持続性ツールから内部の作業単位をラップする、独自のアプリケーション固有の作業単位インターフェースまたはクラスを作成したい場合もあります。これを行う理由はいくつかあります。アプリケーション固有のロギング、トレース、またはエラー処理をトランザクション管理に追加したい場合があります。おそらく、永続化ツールの詳細をアプリケーションの残りの部分からカプセル化したいでしょう。後で永続化テクノロジを簡単に交換できるようにするために、この追加のカプセル化が必要になる場合があります。または、システムのテスト容易性を向上させたい場合もあります。一般的な永続化ツールからの組み込みの Unit of Work 実装の多くは、自動化された単体テストのシナリオでは扱いが困難です。
質問に戻ります。
DbContext と DbSet を直接使用する必要がありますか、それとも自分のリポジトリが必要ですか?
実際、リポジトリにDbContextとを入れても問題はありません。DbSetもっと簡単にテストしたいか、そうでないかを自分で尋ねます。フレームワークを設計したい場合は、使用しないすべてのものをテストしDbContext、DbSet直接Repositories. IDbContextFactory提供するために使用されるインターフェイスを使用する必要がありますDbContext。
リポジトリに関する多くのビューを作成するには、以下のリンクを参照して、リポジトリと の間のオプションを検討してくださいDbContext。
http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
DbContextを直接使用しても問題はありませんか?
DbContextいいえ、直接使用しても問題ありません。しかし、データベースを集中化するため、多くのビジネス ルールが乱雑になり、大量のスケールアップの問題が発生し、テストが困難になり、設計原則の個別の懸念事項に違反します。
将来、MS SQL から Oracle に切り替えたらどうですか?
実際、将来的にMS SQLとOracleを切り替えても問題ありません。DbContextEntity Frameworkを使用する場合は、以下のリンクに従ってデータ プロバイダーを変更するだけです。
于 2013-05-03T04:02:33.983 に答える