問題タブ [objectcontext]

Entity Framework、SQL、および C# を使用しています。

私はClientと呼ばれるテーブルとclients_phoneと呼ばれるテーブルを持っています。

Xtragrid を含むフォームがあり、BindingSource を使用して IQueryable をグリッドにバインドします。

次に、クライアントに新しい client_phone を追加したいと思います。これを行うには、New Client() を作成し、電話を追加します。

最後に、ObjectContext に新しい client_phone を追加しましたが、Xtrag の client_phone が表示されません。

何が起こるかのアイデアはありますか??。

ありがとう

データベースとの間で操作を公開する Web サービスがあります。DAL には Entity Framework 4 を使用しています。

データベースとの間の操作を処理する最良の方法は何だろうと思っています。ObjectContext のインスタンスを維持するのではなく、データベースに対して実行される操作ごとにインスタンスを作成するのが最善でしょうか? これはこれを処理するための非常に悪い方法のようですが、データベースに加えられた変更に追いつくための別の方法は考えられません.

同じコンテキストを維持すると、データがいつ変更されたかをどのように知ることができますか? データベースにクエリを実行するとき、ObjectContext は主キー フィールドをチェックして、レコードが追加または削除されたかどうかをチェックするだけであることを理解しています (私は正しいですか?)。その場合、特定のオブジェクトを更新するように明示的に指示する必要がありますが、これはあまり実用的ではありません。

タイムスタンプ列が使用され、objectcontext がその列の変更をチェックするソリューションを考えています。その列が変更されると、データが更新されます。そのようなソリューションは Entity Framework 4 内に構築されていますか? または、リクエストごとに ObjectContext を再作成せずにデータベースから常に最新のデータを取得する方法について、他に提案はありますか?

私はこの問題で1週間以上立ち往生しています。うまくいけば、誰かが私を正しい方向に向けることができます。

まず、スキーマの簡単な説明から始めます。

資産1--->1住所*->1地域*->1地域*->1国

パッケージ1->*アセット

自己追跡エンティティ（STE）+WCFを使用します。

手順：

1. アセットのリストについては、データストアに電話してください。
2. パッケージのリストについては、データストアに電話してください。
3. ユーザーがパッケージを選択し、それにいくつかのアセットを割り当てます。
4. パッケージを保存します。

ステップ2では、呼び出しはアドレスの積極的な読み込みを使用します。

これは、電話をかけようとしたときのエラーです

オブジェクトのキー値がObjectStateManager内の別のオブジェクトと競合しているため、AcceptChangesを続行できません。AcceptChangesを呼び出す前に、キー値が一意であることを確認してください。

編集

詮索した後、これはSTEの問題であることがわかりました。ここで概説したように、同じエンティティの複数のインスタンスを含むグラフを永続化できないという問題があります。これが私の質問です。

エンティティコレクションにエンティティを追加するにはどうすればよいですか。新しいエンティティには、すでにコレクションにあるものと同じキーを含む関連エンティティが含まれている場合があります。つまり、同じ住所、地域、地域、または国のエンティティを含む可能性のある新しいアセットを追加します。

これが私の制約です：

1. UIに影響するため、ナビゲーションコレクションを使用する必要があります。
2. データセットが大きすぎるため、関係するすべてのエンティティをプリフェッチできません。
3. 履歴を保持し、それを使用して変更を「元に戻す」には、いつでもエンティティのスナップショットを撮ることができなければなりません。

私はDiegoBVegaによって提案された可能な解決策を知っていますが、それらは私の解決策に使用できるオプションではありません。他に何かアイデアはありますか？

EF Context と Testenity があるので、次のテストを実行したいと考えています。

SaveChanges() で動作することはわかっていますが、エンティティをdatasourceに保存したくありません。

このMSDNドキュメントからの言い換え...

INSERTステートメントはEntityFrameworkによって生成され、ObjectContextでSaveChangesが呼び出されたときにデータソースで実行されます。

INSERT操作が成功すると、サーバーで生成された値がObjectStateEntryに書き戻されます。SaveChangesの実行の最後にAcceptChangesが自動的に呼び出されると、サーバーで生成された新しい値を使用して永続的なEntityKeyが計算されます。

これは私のコードでは発生していないようです。を呼び出すとObjectContext.SaveChanges()、次の値UpdateExceptionがスローされます。InnerException.Message

「重複するキー値が一意性制約student_term_data_pkeyに違反しています」

問題のあるコードは次のとおりです。

StudentTermData.IdエンティティデータモデルでEntityKeyとしてマークされていることを確認しました。誰かアイデアや提案はありますか？

次のリポジトリがある場合：

クエリが実行されたときにのみ接続が開かれることを理解しています。

この場合でも、リポジトリにIDisposableを実装させる必要がありますか？

Visual Studio Code Metricsは、確かにそうすべきだと考えています。

IQueryableを使用しているのは、サービスレイヤーへのクエリ（フィルター、ページングなど）を制御できるためです。したがって、IQueryableを使用しているという事実についてアーキテクチャ上の議論をしないでください。

ところで-SqlDataContextは、Entity FrameworkのObjectContextクラスを拡張するカスタムクラスです（POCOパーティを持つことができます）。

だから質問-私は本当にIDisposableを実装する必要がありますか？

もしそうなら、各メソッドが同じリポジトリインスタンスを共有するので、これがどのように可能かわかりません。

編集

Depedency Injection（StructureMap）を使用して、具体的なリポジトリをサービスレイヤーに注入しています。このパターンはアプリスタックをたどります-私はASP.NETMVCを使用しており、具体的なサービスがコントローラーに注入されます。

言い換えると：

1. ユーザーがURLをリクエスト
2. 新しいリポジトリインスタンスで作成された新しいServiceLayerインスタンスを受け取るコントローラーインスタンスが作成されます。
3. コントローラはサービスでメソッドを呼び出します（すべての呼び出しは同じリポジトリインスタンスを使用します）
4. リクエストが処理されると、コントローラーはなくなります。

ハイブリッドモードを使用してコントローラーに依存性を注入しています。これにより、StructureMapのドキュメントによると、インスタンスがHttpContext.Current.Itemsに格納されます。

だから、私はこれを行うことはできません：

これがDIの全体のポイントを打ち負かすので。

これが理にかなっていることを願っています。Entity Framework を使用する ASP.NET Web アプリケーションがあります。いくつかのカスタム テーブルを db に追加し、それらのテーブルの CRUD 操作を処理する別のプロジェクトを作成しました。アプリケーションの将来のアップグレードでカスタム機能が上書きされないようにするため、別のプロジェクトを選択しました。

私の問題はこれです。カスタム ObjectContext をアプリケーションの ObjectContext にアタッチ/結合するにはどうすればよいですか? 同じ UnitOfWorkScope (既にアプリケーション内) を使用して、HTTP 要求ごとに 1 つの ObjectContext インスタンスを維持したいと考えています。繰り返しますが、上記の理由により、ObjectSet をアプリケーションの ObjectContext に追加したくありません。

ここにいくつかのコードがあります：

Widget.cs

WidgetObjectContext.cs

私の WidgetManager クラスでは、アプリケーションの ObjectContext を使用していた場合、次のようにテーブルをクエリします。

私がしたいのは、次のようなことです：

これがうまくいかないことはわかっていますが、それが私が達成しようとしていることの要点です。これが十分に明確であることを願っています。ありがとう。

ObjectContext を手動で初期状態にクリア/リセットする方法はありますか? 新しいコンテキストをインスタンス化することはできないことに注意してください。

これは 1.0 バージョンの Entity Framework を使用しています。

ありがとう

同時に更新したいエンティティがいくつかあります。ただし、エンティティごとに、各クラスの部分クラスファイルに個別の更新メソッドを記述し、それらをすべて同時に呼び出したいと思います。例えば：

私の質問は、オブジェクト コンテキストをどのように管理するのですか? UpdateAll() を呼び出しているクラスで 1 つのオブジェクト コンテキストを作成し、それをパラメーターとして個々の更新メソッドに渡しますか? それとも、更新ごとに新しいコンテキストを作成する必要がありますか? オブジェクトが関連しているため、同じコンテキストを使用したいと思います。これにより、すべてのレコードを更新するための db 呼び出しが減少します。

私は、.NET アーキテクトの第一人者である上級開発者と一緒に働いています。私たちは過去 6 か月以上にわたって多くの建設的な議論を行ってきましたが、通常、私はほとんどの議論で敗北を認めています。私は彼と一緒に仕事をすることでスタックを学びました。しかし、私たちが現在同意していない設計上の問題が 1 つあります。彼は私に彼の立場を納得させることができていないので、意見や提案が欲しいです。誰かが私が間違っています。

Entity Framework 4.0 を使用し、さまざまなモデルで持続性認識と自己追跡エンティティの両方を使用しています。Silverlight アプリケーションへの WCF ワイヤを介してシリアル化/逆シリアル化したエンティティ グラフへの変更を追跡するために、Self Tracked Entities の使用を開始しました。それは素晴らしく機能します。また、WCF 全体で使用していないモデルに Self Tracked Entities の使用を開始しましたが、多くは永続的な認識エンティティ/モデルのままです。

私の同僚は、Entity Frameworks ObjectContext は可能な限り短い時間だけ保持する必要があると考えています。彼は、クエリを実行するのに必要な時間と、何かを永続化するのに必要な時間だけ存在するべきだと主張しています。エンティティで行われるすべてのビジネス作業は、切り離して行う必要があります。エンティティ モデルごとに、IDisposable であり、インスタンス スコープで ObjectContext を持ち、メソッドにクエリ/永続化ロジックを持つクエリ クラスと永続クラスがあります。ビジネス ロジックで ObjectContext を直接使用するのではなく、これらのクエリ/永続化クラスをビジネス ロジックで使用します。これらのクラス インスタンスが構築されると、ObjectContext が構築され、Disposed されると、ObjectContext が Disposed されます。

まず、非セルフ トラッキング エンティティについて考えます。

彼がこれを望んでいる理由と、長時間実行される ObjectContext を持たないことを望んでいることは理解していますが、私の問題は、彼が常に些細なビジネス ロジックでさえも ObjectContext から分離することを望んでいることと、設計の下に別のクエリと永続化コンテキストがあるという事実です。ビジネス ロジックで使用されているエンティティの ObjectContext 状態追跡がないことを意味します。非セルフ トラッキング エンティティの場合、これは、ビジネス ロジックでエンティティを変更する場合、永続化する前に手動でエンティティの Modified 状態を設定する必要があることを意味します。複数の変更を伴う複雑なグラフを永続化する場合、これは非常に苦痛です。また、EFが自動的に行うのと同じように手動で行うこともできないと思います。

セルフ トラッキング エンティティの場合、この状況は同じです。なぜなら、トラッキングはグラフが逆シリアル化されたときにのみオンになるためです。そのため、クエリが実行され、コンテキストから切り離されたサービス内で作業している場合、セルフ トラッキング エンティティでのトラッキングはまだ行われていません。 .

私の質問は、Entity Framework を使用するためのベスト プラクティスは何ですか? また、Entity Framework DAL はどのように設計する必要がありますか? ObjectContext はどのくらいの期間存在する必要がありますか? ビジネス ロジックは常に ObjectContext から切り離して実行する必要がありますか? もしそうなら、ObjectContext から切り離して作業しているときに、どのように状態追跡を行うのでしょうか? 私が考えている 1 つのオプションは、すべてのエンティティを Self-Tracked Entities に変換し、いくつかのグラフ トラバーサル コードを使用してクエリされたグラフをトラバースし、グラフ内のすべてのエンティティの追跡をオンにして、サービス側で作業しているときでもセルフ トラッキングがオンになるようにすることです。 (基本的に、Self-Tracked Entities グラフが逆シリアル化されたときに何が起こるかを模倣します)...

ObjectContext を長期間保持することを提案しているわけではありませんが、クエリと永続性の間で切り離された作業を行って、ObjectContext の状態追跡の利点を失うことはばかげているように思えます...EntityFramework の大きな利点の 1 つを失っています。 ..

長い投稿で申し訳ありません...助けていただければ幸いです。