0

EnterpriseEFでJulieLermanのビデオを見終わったところです。特に、カスタムデータコンテキストの概念が気に入っています。これにより、それぞれのUIをよりきめ細かく制御できるようになります。

ジュリーはすべてのリポジトリにCRUDメソッドを持っていますが、それは私の好きなものにはあまりにも多くのコーディングです。他のリポジトリから派生する汎用リポジトリを作成する予定です。私は彼女のUOWが好きではありませんでした。

リポジトリに関連するため、このアプローチをUOWに使用する予定です。

https://codereview.stackexchange.com/questions/14226/generic-repository-and-unit-of-work-code

カスタムデータコンテキストオブジェクトとの相対条件：

  1. 私が作成すると仮定しましょう：

    私。完全なCustomerクラスの部分的なプロパティのみを持つCustomerLookupクラス。

  2. 私も作成します

    私。CustomerLookupデータベースコンテキスト

    ii。完全なOrdersクラスを持っているが、構成内の関連するエンティティShippingを無視するOrdersLookupdbコンテキスト。

上記のリンクのUOWの例に従うと、UOWはFULLDbContextを使用して変更を保存します。

質問：

  1. 例としてAPIコントローラーでUOWをインスタンス化して、特定のデータコンテキストを使用できるようにすることは可能ですか？

    私。UOW.CustomerLookupRepository.Update（customerLookup）を使用したCustomerLookupContext？

    ii。OrdersLookupContextとUOW.OrdersLookupRepository.Update（order）？

コンテキストオブジェクトをUOWから切り離せない場合：

  1. 上記のような部分クラスの更新で問題が発生しますか？また
  2. DbContext全体を使用するとパフォーマンスに影響しますか。また、
  3. 何について話しているのかわからないので、UOWの完全なDbContextを使用しますか？

ありがとう

4

1 に答える 1

1

アプリにはdbcontextを1つだけ含める必要があります。2つの異なるデータベースにアクセスする必要がある場合など、例外がありますが、それでも、SQLServerシノニムを使用してそれらを単一のデータベースにマップすることを好みます。

アプリに複数のコンテキストを配置することには、非常に現実的な問題があります。多くのコンパイラエラーが発生し、名前空間の衝突に対処する必要があります。それを回避することは可能ですが、それは大きな苦痛です。

用途ごとに異なるコンテキストを作成してもメリットはありません。dbcontextの要点は、データベースへのフルアクセス権を持ち、さまざまなエンティティに変更を加えてから、すべての変更を1回の操作で保存できることです。

あなたは何を得ていると思いますか？データベース全体をメモリにロードするわけではありません。

于 2012-09-27T17:48:42.197 に答える