問題タブ [self-tracking-entities]

STEを使い始めた MVC2 アプリがあります。更新がどのように機能するかについての明確化を探しています。

バックグラウンド：

関連カテゴリ エンティティと関連投稿/コメント エンティティを含むブログ エンティティがあるとします。MVC では、メインのブログ エンティティとカテゴリを含むビューをレンダリングしていますが、関連する投稿はレンダリングしていません。ブログ エンティティをサーバーにポストバックすると、関連するカテゴリは表示されますが、サーバーにシリアライズされるエンティティの投稿は表示されません (ビューに表示されていないため)。また、ブログ エンティティの変更状態は「追加済み」です。

次に、このブログ エンティティを呼び出して更新を実行しようとしApplychanges()ましSaveChanges()たが、投稿との FK 関係と、データベースに関連する投稿があるが、返信しているエンティティに関連付けられていないという事実のために失敗します。

さらにテストを行って... サーバーに接続しているときに (状態 = 変更なし)、ブログ エンティティの現在のインスタンス (関連するすべての FK エンティティを含む) を取得し、プロパティを変更 (状態 = 変更済み) して更新すると、期待どおりに動作します。 .

私の質問: ビューにレンダリングされていない関連エンティティがあり、そのためブログ エンティティでポストバックされない場合、更新は機能するはずですか?

ブログ エンティティが「変更済み」ではなく「追加済み」ステータスのポスト バックを取得するのはなぜですか? 変更されたすべてのエンティティに対して「変更された」変更状態が返されると想定し、ApplyChanges/SaveChanges()変更されたアイテムのみを呼び出すと更新が試行されるため、関連するすべてのエンティティは必要ありません。

クライアントからエンティティを直接渡すことができるようにする必要がありますか、ApplyChanges()/SaveChanges()またはエンティティをサーバーにポストバックし、データベースから既存のコピーを取得し、そのコピーに変更を適用して、既存のオブジェクトをポストバックする必要がありますか?

EF4 Self Tracking Entities (VS2010 Beta 2 CTP 2 と新しい T4 ジェネレーター) を使用しています。しかし、エンティティ情報を更新しようとすると、期待どおりにデータベースに更新されません。

2 つのサービス コールをセットアップします。1 つはリソース オブジェクトを返す GetResource(int id) 用です。2 番目の呼び出しは SaveResource(Resource res) です。これがコードです。

ChangeTracker.State は常に「Unchanged」と表示されるようです。

このコードに何か問題がありますか？

昨年、Entity Framework (もちろん .NET3.5) を使用し、Julie Lerhman の本をガイドとして使用して、プロジェクトのデータ アクセス サービスを開発しました。状態追跡 POCO オブジェクトを開発しました。WCF を使用し、Silverlight 3 クライアントもあります。私たちは .NET 4.0 に移行しており、コード生成の使用に切り替えて、POCO クラスと翻訳クラスを作成する開発者の無駄な時間をなくしたいと考えています。

私が行った調査では、POCO を追跡する状態には 3 つの方法があるようです。

1) 追跡されたプロキシの変更: これは WCF シリアル化では機能しないように見えるため、役に立たないようです。

2) スナップショット ベース: POCO エンティティ グラフが取得されたときにスナップショットが取得され、クライアントから返されたグラフがそのスナップショットと比較され、差異が比較されます...私には良いようです。

3) 自己追跡エンティティ: コード ジェネレーターは、POCO オブジェクト内で自己追跡を行うためのロジックを生成します。これは、すべてが私たちのために生成されていることを除けば、現在私たちが行っていることに近いようです。

これらすべての方法の長所と短所を理解しようとしています。1 と 2 は「接続」されており、インスタンス化されたままにするために POCO が最初に照会された ObjectContext が必要であると推測していますが、これを確認することはできませんでした。また、オプション 3 が同じかそれ以上のことを行うように見えることを考えると、誰もがオプション 1 を実際に気にする理由もわかりません...

スナップショットは私にとって最も単純なように思えますが、これが ObjectContext を長時間開いたままにする必要があるかどうかはわかりません...

私はジュニア プログラマーに過ぎないので、特に Silverlight 3 に関して (オプション 2 と 3 は Silverlight 3 で動作すると思いますが、オプション 2 には問題がある可能性があります)、ここでのアドバイスは大歓迎です。

セルフ トラッキング エンティティ。素晴らしい。

あなたが何かをするときを除いて

自己追跡エンティティは追跡されません (おそらく逆シリアル化されるまで)。

罰金。したがって、私たちに戻ってきたエンティティが追跡を有効にしていない可能性があることを認識する必要があります。

それで？？？

私が試したこと

指定されたメソッド本体の場合:

次の実装はFigureItOutすべて失敗します。

または

または

または

また、私がそれに投げかけることができると考えることができる他のことについても、

1. データベースから元のエンティティを取得する
2. 各プロパティを手で比較する
3. 必要に応じてプロパティを更新する

正確には、自分自身を追跡していない自己追跡エンティティをどうすればよいのでしょうか??

小さな更新:

エンティティを変更済みとして盲目的にマークすることはできますが、これは少し臭いようです。この場合、私たちができる最善のことですか？

EntityFrameworkを使用してPatientEntities用のWCFデータサービスをまとめています。

私のソリューションは、これらの要件に対処する必要があります。

• エンティティPatientのプロパティDateOfBirthは、SQLServerに文字列として格納されます。エンティティクラスが「文字列」型ではなく、DateTime型も使用するのが理想的です。（ストレージレイヤーから抽象化するため、これが可能になると思います）。エンティティとSQLServerが同期するように、DateTime / stringとの間で変換する変換メカニズムをどこに配置できますか？ストレージレイヤーの構造を変更できないため、回避する必要があります。
• クライアントはLINQ式を使用してサービスを利用できるため、WCFデータサービス（読み取り専用なので、変更を保存する必要はありません）を使用する必要があります。GetPatient（int ID）などの単一のメソッドに制約されることなく、必要な任意のクエリシナリオに基づいて結果を生成できます。

DTOを使用しようとしましたが、ObjectContextをDTOにマッピングする際に問題が発生しました。理論的には可能ではないと思います...または、可能であれば複雑すぎます。

自己追跡エンティティを使用しようとしましたが、正しい場合は.edmxファイルのメタデータが必要であり、これにより別のプロパティデータ型が許可されません。

また、エンティティゲッターメソッドにカスタマイズを追加して、タイプ「string」のプロパティ「MRN」が返される前に.Replace（ "MR〜"、string.Empty）を実行する必要があるようにします。これをgetterメソッドに追加できますが、Entity Frameworkが次にエンティティクラスを更新するときに、これを上書きするという問題があります。これらを置くことができる恒久的な場所はありますか？

代わりにPOCOを使用する必要がありますか？それはWCFデータサービスでどのように機能しますか？サービスはどこでメタデータを取得しますか？

Entity Frameworks 4 と自己追跡エンティティを使用してプロジェクトを作成しています。SQL Server 2008 データベースまたは SQL Server Compact データベース (構成ファイルにあるスイッチを使用) からデータを取得できるようにしたいと考えています。私はリポジトリ パターンを使用しており、セルフ トラッキング エンティティを別のアセンブリに配置します。

2 つの edmx ファイルが必要ですか? その場合、別のアセンブリで STE のセットを 1 つだけ生成するにはどうすればよいですか? また、2 つのコンテキスト クラスも生成する必要がありますか? このすべての配管がわかりません。誰でも助けることができますか？

ダレン

2 つのデータベースは同一であり、コンパクト バージョンはオフラインで使用するためのものであることを付け加えるのを忘れていました。

私はセルフ トラッキング エンティティを使用しており、「リンクとして追加」を使用してエンティティ クラスを別のアセンブリに移動し、ここで説明したように TT ファイルをポイントしました。ただし、モデルを更新すると (たとえば、プロパティ名を変更すると)、テンプレートは自動的に実行されないため、エンティティ クラスは更新されません。

もちろん、テンプレートを手動で実行して更新を取得することもできますが、クラスを移動する前と同じように自動的に実行した方が簡単です。これを達成する方法はありますか？

ダレン。

EF4 の継承されたエンティティ (TPT) で奇妙な現象が発生しているように見えます。

私は3つのエンティティを持っています。1.資産 2.財産 3.活動

Property は Asset の派生型です。プロパティには多くのアクティビティがあります (多対多)

これを EDMX でモデル化すると、データベースに新しいプロパティを挿入しようとするまで、すべて問題ないように見えます。プロパティにアクティビティが含まれていない場合は機能しますが、新しいプロパティにいくつかの新しいアクティビティを追加すると、すべてが崩壊します。

Web をクロールして 2 日間いじった後、EF ストア (SSDL) でエンティティ間の制約の一部が更新プロセス中に取得されていないことに気付きました。

プロパティとアクティビティをリンクする Property_Activity テーブルには、FK_Property_Activity_Activity という制約が 1 つしか表示されませんが、FK_Property_Activity_Property がありませんでした。

データベースの関係を次のように切り替えたとき、これが Entity Framework の異常であることはわかっていました。

Asset <--> Asset_Activity <--> アクティビティ

更新後、新しいプロパティでのアクティビティの有無にかかわらず、すべての外部キー制約が取得され、保存が成功します。

1. これは意図したものですか、それとも EF のバグですか?

2. この問題を回避するにはどうすればよいですか?

3. 継承を完全に放棄する必要がありますか？

多層ビジネスアプリケーションにはObservableCollections、サービスコールから返される自己追跡エンティティがあります。

アイデアは、エンティティを取得し、それらをコレクションクライアント側に追加、更新、および削除してから、これらの変更をサーバー側に送信して、データベースに永続化できるようにすることです。

自己追跡エンティティは、その名前が示すように、自分の状態を追跡します。新しいSTEが作成されると、追加状態になります。プロパティを変更すると、変更状態が設定されます。削除状態にすることもできますが、エンティティがObservableCollection（明らかに）から削除されると、この状態は設定されません。この動作が必要な場合は、自分でコーディングする必要があります。

私の現在の実装では、エンティティがから削除されたObservableCollectionときに、それをシャドウコレクションに保持します。これObservableCollectionにより、がサーバーに返送されたときに、削除されたアイテムを一緒に送信できるため、EntityFrameworkはそれらを削除することを認識します。

次のようなもの：

これで、ユーザーが変更をサーバーに保存することにした場合、削除されたアイテムのリストを取得して、それらを一緒に送信できます。

この時点で、UpdateCustomersメソッドはアイテムが削除されたかどうかをシャドウコレクションで確認し、それらをサーバー側に送信します。

これらのシャドウコレクションのライフサイクルについて考え始めるまで、このアプローチは問題なく機能します。基本的に、ObservableCollectionガベージコレクションの場合、辞書からシャドウコレクションを削除する必要があることを知る方法はありません。

この場合、基本的に手動のメモリ管理を行う複雑なソリューションを思いつきました。私はを維持し、WeakReference数ObservableCollection秒ごとに参照が非アクティブであるかどうかを確認します。その場合、シャドウコレクションを削除します。

しかし、これはひどい解決策のようです...StackOverflowの集合的な天才がより良い解決策に光を当てることができることを願っています。

編集：

結局、私はサブクラス化することにしましたObservableCollection。サービスプロキシコードが生成されるため、派生型を返すように変更するのは比較的簡単な作業でした。

すべての助けをありがとう！

私はエンティティ フレームワークを、最新の Silverlight から WCF アプリケーションへのセルフ トラッキング エンティティ コード生成テンプレートと組み合わせて使用​​しています。実際のプロジェクトでエンティティ フレームワークを使用するのはこれが初めてであり、データベース スキーマが変更されたときにプロジェクトのデータ アクセス レイヤー全体を自動的に更新できるようにすることで、多くの時間と労力を節約できることを願っていました。

幸いなことに、新しいテーブルの追加、列名の変更、新しい列の追加などによるデータベース スキーマの更新は、エンティティのデータベース オプションからの更新を使用して、ビジネス オブジェクト クラスに伝播できることがわかりました。フレームワーク モデル。

私が苦しんでいるのは、Silverlight クライアントでのアクションに対応する WCF サービス内の CRUD 操作です。Silverlight アプリで同じセルフ トラッキング エンティティ フレームワーク ビジネス オブジェクトを使用していますが、オブジェクトの更新時に外部キーの関連付けが正しく処理されない、または変更トラッカーがオブジェクトの状態について混乱するなどの問題と常に戦わなければならないことがわかりました。 Silverlight エンドのオブジェクトと、WCF レイヤー内のデータ アクセス操作がぐらつきます。

独自のビジネス オブジェクトをローリングするための出発点として Linq-to-SQL を使用した以前のプロジェクトよりも、この癖に対処するのに多くの時間を費やしたところまで来ました。

それは私がどうしようもないだけなのですか、それとも自己追跡エンティティが、より成熟するまで避けるべき何かに近づいているのでしょうか?