18

質問

MVC Webアプリの複数のリポジトリ間でEFDbContextを共有する適切な方法は何ですか？そうすることは賢明/必要ですか、これを行うか行わないかの落とし穴は何ですか？

バックグラウンド

推定：

  • App.MvcSite（数十のコントローラー、複数の領域など）
  • App.Services（サービスレイヤー、多くのサービス）
  • App.Data（多くのリポジトリなど）
  • ...簡単にするために除外されたその他（EFコード最初の最新）

これまでの研究

私は、SOとインターウェブについて少なくとも2つまたは3つの考え方を見つけているようです。

  1. DbContextをリクエストに共有/スコープして、単一のリクエストがすべてのリポジトリで共有される単一のDbContextを持つようにします。
  2. サービスレイヤーでDbContextを共有/スコープします-サービスは単一のDbContextを維持し、必要に応じてそれを各リポジトリに渡します。
  3. DbContextは安価であるため、共有しないでください。各リポジトリに独自のリポジトリを持たせてください。

小さなウェブサイトでは、これは問題ではありません。そのため、ほとんどのMSやコミュニティの例ではこれに対処していません。

これまでの私の経験では、有限のリポジトリを使用していません。私はいつもサービスにDbContextを使用させ、それを直接変更させてきたので、これについて心配する必要はありませんでした。ユニットテストの観点から、有限リポジトリには大きなメリットがあると言われています...それが残りの部分を価値のあるものにするかどうかを確認します。

私の考え

（1）DbContextをリクエストに共有/スコープする

これは、一部の開発者が答えだと思うシングルトンコンテキストの落とし穴を賢く回避するので興味深いですが、DbContextはそのようには機能しません。しかし、すべてのリポジトリやサービスなどがリクエスト全体で調整されることを前提としているという欠点があるようです...これは多くの場合そうではありませんよね？別のリポジトリが作業を完了する前に、あるリポジトリによって変更が保存された場合はどうなりますか。（outer（inner（inner）））

（2）サービスレイヤーでDbContextを共有/スコープする

各サービスは特定の作業単位（小文字は意図的）を調整する必要があるため、これは私にとってより理にかなっています。したがって、1つのリクエストで複数のサービスが使用された場合、それぞれがデータベースへの独自のコンテキストを持っていることが適切です（必須でない場合）。

（3）DbContextは安価なので、共有しないでください

これは私がいつもやってきた方法です...実際には、1つのサービスしか呼び出されていなかったため、ほとんどの場合、リクエストごとに1つのDbContextしかありませんでした。作業を調整しているコントローラーによって2つのサービスが呼び出されたため、2つになる場合があります。しかし、多くの有限リポジトリを持つ現在のアプリケーションを考えると、各リポジトリが独自のコンテキストを持っているということは、特定のリクエストに3〜10個のDbContextのインスタンスがあることを意味します。私はこれが問題があると（おそらく間違って）思います。

質問を繰り返す：

MVC Webアプリの複数のリポジトリ間でEFDbContextを共有する適切な方法は何ですか？そうすることは賢明/必要ですか、これを行うか行わないかの落とし穴は何ですか？

4

2 に答える 2

5
  • DbContext安価ですが、分散トランザクションはそうではありません。
  • あるコンテキストにアタッチされたオブジェクトを別のコンテキストで使用することはできません（オブジェクト関係がある場合）

コンテキストを共有する最も簡単な方法は、制御の反転コンテナの使用を開始することです：http: //www.codeproject.com/Articles/386164/Get-injected-into-the-world-of-inverted-dependenci

于 2013-02-27T13:48:05.523 に答える
1

私は最初の2つのオプションの組み合わせを選び、最初のオプションの考え方については、リポジトリに変更を保存させないでください（これは推奨される方法ではありません、Martin Fowlerは自分自身だと言っています）。作業単位パターン。

于 2013-02-27T23:35:11.203 に答える