0

私のスパでは、エンティティをデータベースに保存する前に、複雑なオブジェクト ツリーをクライアントに送信し、ユーザーにデータを入力させる必要があります。したがって、エンティティはその時点ではデータベースに存在しません。オブジェクト ツリーはサーバーのメモリ内に構築され、 を呼び出すだけで取得されますbreeze.EntityQuery.from("ComplexeObjectTree")。エンティティは、ノックアウトを介して Web フォームにバインドされます。ユーザーは、保存ボタンを押す前に、まず必要なデータを入力します。フォームのエンティティ プロパティの一部はオプションであり、デフォルト値があります。ユーザーがこれらのプロパティを変更しない場合、beeze は変更を検出せず、所有するエンティティを変更セットに入れません。それらは変更されていないとマークされていますが、それらの id 値はまだです-1(まだ保存されていません)。ただし、データベースの保存は、関係を含むオブジェクト ツリー内のすべてのエンティティがサーバーに送信された場合にのみ正常に実行できます (データベースの制約を尊重するため)。保存操作の結果、1 つまたは複数の挿入ステートメントが生成されます。これは、クライアントでは変更されていないが、データベースにとっては新しいエンティティに対しても同様です ( id==-1)。このユースケースをどのように処理できますか? 追加済みとしてマークされた主キーを持つすべてのエンティティをid==-1、デフォルトで保存変更セットの一部にするべきではありませんか?

どんな助けでも大歓迎です、

アンドレアス

4

3 に答える 3

1

オブジェクトグラフはサーバー上で構築する必要があるというあなたの主張を受け入れましょう。私の理解が正しければ、永続的なストレージにコミットする前に、サーバー上で生成した値の一部を微調整する機会をユーザーに提供していることになります。良い計画のように聞こえます。

「ComplexObjectTree」はエンティティ グラフである必要はありません。任意のデータ オブジェクトにすることができます。それは依然として CLR 型である可能性がありますが、メタデータで記述されたオブジェクトではなく (またはオブジェクトを含んでおらず)、EF や Db にも認識されません。このオブジェクト グラフは、クライアント上で実際のエンティティ グラフを構築するための情報として存在します。クライアントで計算したくない、計算が難しい値がすべて含まれています...人生の意味に対する答えや、今年のスーパーボウルの優勝者などです。

クエリは、データを含むこのオブジェクトを返しますが、エンティティは返しません。querySuccess コールバック は、このデータからクライアントのエンティティ グラフを作成しCreateComplexTree(data)ます。

エンティティ グラフは、メタデータのおかげで、Breeze クライアントが理解できるエンティティで構成されます。異議がない限り、これらのエンティティもサーバー上で認識され、他のエンティティと同様に保存してクエリを実行する準備ができています (false の場合は、その仮定を回避できますが、一度に 1 つの問題に取り組みましょう)。

これで準備完了です。データ グラフをたどりながら、エンティティを作成します。データに (-1) が表示されている場合は、その型の新しいインスタンスを作成する必要があることがわかります。の第 2 引数であるエンティティ初期化オブジェクトにデータをコピーしますmanager.createEntity('Foo', {...})。ここにはビジネス ロジックはありません。計算もありません。単にコピーするだけです。

グラフ内のすべてのオブジェクトを挿入するのか、それとも一部だけを挿入するのかわかりません。それらのいくつかは、ユーザーが変更しない限り変更されない既存のエンティティである可能性があります。大したことはありません。のような行を使用して、同じアプローチに従って、クライアントで「変更されていない」エンティティを構築できますmanager.createEntity('Bar', {...}, breeze.EntityState.Unchanged)

これで、適切な Breeze エンティティ グラフが作成され、バインド、ナビゲート、および保存の準備が整いました。ユーザーがサーバーが作成した方法でそれを気に入った場合、[保存] ボタンを押すと、Breeze はエンティティ グラフ内のすべての変更を検出し、サーバーに移動します。

Bryant が指摘するように、クライアントを本当に信頼することはできません。グラフをたどって検証する必要があります。しかし、それはあなたの方法論に関係なく真実です。

お役に立てれば。

于 2013-01-25T19:26:06.320 に答える
1

通常、サーバーではなくクライアントでエンティティを作成します。そうすれば、エンティティは新しくなり、save メソッドに保存されます。

エンティティはサーバーから送信され、クライアント上で変更されていないため、エンティティが戻ってきたときにサーバーがエンティティを処理する理由はありません。

したがって、クライアントで新しいエンティティを作成してから、変更の保存を呼び出します。

于 2013-01-25T15:46:16.887 に答える
0

ブライアントの答えは完全に正しいです。この答えは、単に明確にするためのものです。

私が質問を理解しているかどうかは完全にはわかりませんが、明確にするために、 EntityManager は同じ「キー」を持つ同じタイプの複数のエンティティをサポートしていません(つまり、あなたの場合は-1)。同じキーを持つ単一タイプのすべてのエンティティを「同じ」エンティティとして扱います。

あなたがしたいことは、一連の「偽の」エンティティをentityManagerに取得し、条件付きでそれらのいくつかを「実際の」新しいエンティティに変換して保存し、これらのレコードをデータベースに追加することです。これはあなたが達成しようとしていることですか?

于 2013-01-25T18:34:20.250 に答える