2012-02-03 1 views

答えて

0

このメソッドは、キーのプロパティではなく、エンティティを指すURLを使用します。現在、ほとんどのODataサーバーでは、URLのキープロパティを使用してエンティティに対処するための規約が使用されています。このコンベンションは、http://www.odata.org/developers/protocols/uri-conventions#AddressingEntriesに記載されています。しかし、私は自分自身でURLを作成しようとしないことを強く勧めます(間違ってしまうのは簡単です)。 あなたが働きたいシナリオを投稿した場合は、より良い答えが可能です。

0

私がしようとしているのは、エンティティの一部をローカルにキャッシュすることです。例えば。顧客が州を持っていると仮定します(州には複数のキーがあります)。私は顧客(孤立したストレージ)に状態をキャッシュしたいので、顧客をプルダウンして顧客状態を拡大すると、今は2つのエンティティに顧客と状態というコンテキストがあります。

UIでは、ユーザーが選択できるコンボボックスの状態の一覧が必要な場合がありますが、状態が変わらないたびに状態をプルダウンする必要はありません。したがって、状態を状態のリストにコンテキストに追加する前に、状態がコンテキスト内にあるかどうかを調べる必要があります。これは私がTryGetEntityをしたことです。私は複数の主キー(名前のペアを使って手作業でURLを構築する)を持つエンティティでこれを成功裏に実行することができましたが、それは最高ですが厄介です。

最初に、キーが1つしかない場合は、URLにキー値のペアを使用できないように見えます。 第2に、キーの順番が違いますように思われますか?

私は手動でURLを構成することには問題があることに同意します。それが私が質問した理由です。

明らかに、私の例は現実の状況を簡略化したものですが、私はどこでこれをどう見ているのでしょうか。

+0

TryGetEntityを使用してコンテキスト内に特定の状態が既に存在するかどうかを調べる代わりに、Context.Entities.Where(e => e.Entity.GetType()== typeof(State)&&((State )e.Entity).ID == keyValue);複数のキーに対してもこれらのクエリを書くことができます。コンテキスト内のエンティティの数が膨大でない場合、これのパフォーマンスは悪くありません。 – Pratik

+0

また、独立したストレージにシリアル化する際にエンティティのIDを格納することもできます。インスタンスでGetEntityDescriptorを呼び出し、返されたオブジェクトでIdentityプロパティにアクセスし、それを格納します。後でそれをTryGetEntityのパラメータとして使用できます。 –