問題タブ [dbcontext]

EF 4.1 DbContext Generatorを参照して- 別のプロジェクトにエンティティを配置しますか? 、別の名前空間のエンティティを使用するために DbContext を取得するには何が必要ですか? DbContext テンプレートを編集する必要がありますか (そうであれば、どのように?)、または .edmx を編集する必要がありますか?

MVC3プロジェクトでEF4.1を使用していますが、オブジェクトの挿入に問題があります。私はいくつかのオブジェクトを保持するためにセッションも使用しています。具体的には：

親子関係のある単純なクラスがあります。

プロモーターはCurrentUserに基づいています。私のアプリケーションでは、CurrentUserをhttpセッションに保存します。このようなイベントを追加すると、ユーザー（および関連するすべてのオブジェクト）が新しい主キーでもう一度挿入されます。

ユーザーの状態を確認すると、主キーは0ではなく、EFはそれがすでに永続的であることを認識しているはずですが、「追加」されています。永続性コードに多くを追加せずにこれを修正するにはどうすればよいですか。リクエストごとに、currentuserを新しいdbcontextに再接続する必要がありますか？これにより、dbコードがアプリケーションに「リーク」します。DBのものをデータ層に保持したい。私はこのようなリポジトリを使用しています：

サービス層で DbContext を公開するのは悪い習慣ですか?

例えば：

ここで、IDatabaseFactory は DbContext オブジェクトを返すことができます。ここで公開したのは、SkillLevels 以外のエンティティが必要な場合に、このサービス クラスで使用できるようにするためです。ご存じのとおり、データを取得するために複数のテーブルを選択する必要がある複雑なクエリの場合。

しかし、それが悪い習慣になるかどうかはわかりません!!

どんな助けでも大歓迎です。ありがとう。

以下で説明するシナリオの解決策を見つけるのに時間がかかりすぎました。一見単純な出来事が、かなり難しいことが判明しました。質問は：

Entity Framework 4.1 (Code First アプローチ) と「独立した関連付け」を使用して、「切り離された」シナリオ (私の場合は Asp.Net) で、既存の「多対 1」の関係に別の端を割り当てる方法を教えてください。

モデル:

独立アソシエーションの代わりに ForeignKey リレーションシップを使用することも選択肢の 1 つだったことは理解していますが、Pocos に ForeignKey 実装を持たないことが私の好みでした。

顧客には 1 つ以上のターゲットがあります。

ターゲットには 1 人の顧客がいます。

Customer は Person クラスから派生します。

EntityBase クラスは、いくつかの一般的なプロパティを提供します。

コンテキスト:

MVC 3 + EF 4.1

DbContext を処理するために、次の 2 つのアプローチから選択しています。

1. でインスタンス化しApplication_BeginRequest、 に入れ、 で HttpContext.Current.Items破棄しApplication_EndRequestます。
2. 使い捨ての UnitOfWork (の一種のラッパーDbContext) を作成し、各コントローラー アクションを次のように開始します。using(var unitOfWork = new UnitOfWork()) { ... }

あなたの経験を共有してください: どちらが好きですか? 各アプローチの長所と短所は何ですか?

EF CodeFirst / Mvc3を使用してデータベースに一意のキー検証を実装しようとしているときに、この投稿に出くわしましたhttp://blogs.msdn.com/b/adonet/archive/2011/05/27/ef-4-1 -validation.aspxIValidateObjectは、オブジェクトモデルに使用してそれを行う方法の例を示しています。

とオーバーライドDbEntityValidationResult ValidateEntity：

そして、コントローラーのアクション

しかし、私はエラーを受け取ります："The given key was not present in the dictionary."行のために

オーバーライドValidateEntityコードで設定される前に、「Context」にアクセスするオブジェクトのValidateが呼び出されているようです。

最初は、ModelState.Isvalidトリガーの検証が早すぎる可能性があると思いましたが、そうではありませんでした。

私がここで何が欠けているのか、何が間違っているのか誰かが知っていますか？前もって感謝します。

Order オブジェクトを持つ Customer オブジェクトがあるとします。Order オブジェクトには OrderDetail オブジェクトがあります。

Customer の状態を次のように変更すると、次のようになります。

これにより、oCustomer オブジェクトのみが保存され、oCustomer にある Order および OrderDetail は保存されません。context.Entry(oCustomer).State = EntityState.Modified は oCustomer の状態のみを変更し、Order と OrderDetail は変更しないためです。現在、変更が保存されるように、ObjectGraph 内の各エンティティの状態を手動で変更する必要があります。親エンティティだけでなく、ObjectGraph 全体の状態を変更する方法はありますか? それを行うための拡張メソッドまたは他の方法はありますか?

WCFサービスを公開するアプリケーションを開発しています。DALでEntityFramework4.1を使用しています。問題は、エンティティをロードするときです（たとえば、Orderを持っている顧客がOrderDetailを持っているとします）。ロードした後、Customer、Order、およびOrde​​rDetailオブジェクトにいくつかの変更を加え（いくつかの新しい注文が追加され、いくつかの既存の注文が削除/更新されます）、オブジェクトグラフをWCFサービスに送信して次のように更新します。

サーバー側で更新された顧客のObjectGraphを受け取ったとき、現在変更追跡がないため、どの注文が削除され、どの注文が変更されたかわかりません。どの順序を削除し、どの順序を変更するかをどのように判断できますか？Entity Framework 4.1でオブジェクトグラフの変更を追跡する方法はありますか？

注：以前は、この問題を解決するセルフトラッキングエンティティを使用していましたが、WCFサービスがJavaクライアントアプリでも使用されるため、STEを削除する必要がありました。したがって、STEは私にとってオプションではありません。

シナリオ: あるデータベースから別のデータベースに情報を抽出して再配置しようとしています。DB A には取得したいデータがあります。少し異なる構造でDB Bに保存したいと思います。

DB AI は EDMX データベースで生成されたモデルを使用するため、ObjectContext の派生物を使用します。DB BI はコード生成を希望しています。そのため、パッケージ マネージャーを介して EntityFramework 4.1 をインストールすることにより、コード/モデル ファーストのアプローチを使用します。したがって、DB B は DbContext 派生物を使用します

DB A から DB B に情報を保存しようとすると、次のように表示されます。

テスト メソッド RoutIT.Irma.Import.Service.Test.ImportIrma2ProductTests.ImportProducts が例外をスローしました: System.ArgumentException: 「DB A の EDMX モデル内のエンティティ」の概念モデル タイプが見つかりませんでした

実際には、DB B エンティティを DB B の派生 DbContext の DbSet プロパティに追加するときに実行されます。したがって、コードは次のようになります

上記の矢印 ("<--") でマークされたコード内のポイントで発生します。

FirstPVC は DB B のプロパティですが、矢印の時点で、DB B のコンテキストに属するエンティティの概念モデルがないことに不満を感じています。

DB B エンティティを DB B コンテキストに格納しようとしているので、これは奇妙です。DB A のエンティティを気にする必要があるのはなぜですか。

すべてのコンテキストが同じプロジェクトに含まれています。しかし、DB B の Derived DbContext は、それ自身の DbSet<> プロパティに関する知識しか持っていません。突然、DbSet<> プロパティに何かを追加しようとすると、上記の太字のエラーが表示されます。

なぜこれが起こるのか知っている人はいますか？DbContext が別のコンテキストのエンティティ、特に ObjectContext 派生クラスのエンティティを気にする必要があるのはなぜですか。

おそらく、それが不平を言っているエンティティがこのように見えることに注意することは役に立ちます

私は次のリポジトリインターフェースを持っています

次に、上記のインターフェイスから継承する次のリポジトリクラスがあります

IRepository<>からも継承するFakeRepository<>を作成しました

リポジトリと偽物の唯一の違いは、LinqToSQL DBContextを使用するのではなく、テスト目的で偽物を作成したことです。

次に、単体テストで実行できることは次のとおりです。

したがって、私のテストは常にメモリ内のfakedbcontextに対して実行されます。

ただし、構造マップエラー104プラグインタイプエラーが発生し、理由がわかりません。