2012-01-12 4 views
0

たとえば、名前、姓、電子メール、電話番号などのフィールドを保持する10個のフィールドを持つUserエンティティがあります。 4つのフィールドは公開され、残りの6つは承認されたサブスクリプション(2人のユーザーは友人としてマークされます)を必要とします。WCF Data ServiceおよびEntity Frameworkを使用したエンティティインスタンスごとのフィールドの可視性の制御

このようにデータサービスに問い合わせる場合:http://example.com/users?auth_token=xxx、リクエスタはユーザーごとにアクセスできるフィールドのみを表示する必要があります。これはfacebook APIの仕組みとよく似ています。

WCF用のカスタムデータプロバイダを作成する際に問題が発生し、コレクション全体にルールが適用されていることがわかりました。私が必要とするのは、コレクション内のアイテムごとのルールセットです。私はWCFにフックを書き込んで、渡されたMessageオブジェクトをモーフィングすることを考えましたが、あまりにも多くのオーバーヘッドが関連付けられていると感じています。

誰でも何ができるのですか?あるいは私のニーズを解決するための別のフレームワークですか?

答えて

2

これは、WCF DSとODataの考え方に反するものです。 ODataでは、各エンティティが特定のプロパティセットを持つモデル(EDM)を定義します。そのタイプのすべてのインスタンスがこれらすべてのプロパティを持つことが期待されます。 オープンタイプ(オープンにエンティティタイプをマーク)を使用して、インスタンスごとにオプションのプロパティを追加することもできますが、これらのプロパティはモデルに含まれません。典型的には、これは次のいずれかの方法で解決される

1)2つのエンティティタイプにエンティティを分割。誰もが見ることができる「パブリック」と、許可されたユーザだけが見ることができる「プライベート」のもの。また、公開と非公開のナビゲーションプロパティがあります。この場合、非公開のエンティティ全体を非認証のユーザーから非表示にして、モデル内に表示されないようにすることもできます。 (これは非常に安全で、モデルでは完全に定義されています)。

2)公開タイプとプロパティを使用し、パブリックプロパティのみを宣言してから、要求が許可ユーザーのものである場合のみ、エンティティに公開プロパティを設定します。これは、モデルを追加の型で "ポーリング"するのではなく、プライベートプロパティがモデルで決して宣言されていないことを意味します。

カスタムプロバイダを使用すると、他のものを実装することもできます。カスタムプロバイダは、要求ごとにモデルを変更できます。したがって、権限のないユーザーの場合は、型にはパブリックプロパティのみがあり、許可された場合には型にすべてのプロパティがあります。しかし、それは、その1つの要求の中のそのタイプのすべてのインスタンスに適用されます(上記の#1と#2の両方が、必要な場合はインスタンスベースでこれを実行できます)。これは#1と同じくらい安全で静的な型指定が可能ですが、クライアントは通常、型から要求に応じて変形することを期待しないので、より混乱します。

+0

ご意見ありがとうございます。それは私が恐れていたものです。コードが複雑になるにつれ、いずれのソリューションのファンでもありません。私はEFをきれいにして、他の場所で使用できるようにしたい。ジェネリックハンドラを作成し、テンプレートuriを使用してURLを照合するとします。 –

関連する問題