2

ここにあるカスタム データ プロバイダーに対抗するために、一般的な OData プロバイダーに取り組んでいます。これは、データ プロバイダーが認識しているテーブルをデータ プロバイダーに照会するという点で、完全に動的です。ここまでで、OData サンプル コードに基づいて、基本的なストレージ構造を配置しました。

私の問題は次のとおりです。OData はクエリをサポートしており、IQueryable 実装を渡すことを期待しています。下側では、クエリのサポートはありません。冗談ではありません。プロバイダーはテーブルを返し、WHERE 句はサポートされていません。ここではパフォーマンスは問題になりません。テーブルは小さいです。OData プロバイダーで並べ替えても問題ありません。

私の主な問題はこれです。

  • テーブルのデータを取得する SQL ステートメントを送信します。その結果が、ある種の ADO.NET データ リーダーです。
  • 後でフィルタリングできるようにするには、このデータの IQueryable 実装を公開する必要があります。

それに最もよく触れる方法はありますか？.NET 3.5 のみ (当面は 4.0 の予定はありません)。標準のLINQを使用できるように、すべてのテーブル（バイトコードを発行する）に動的DTOクラスを作成することを真剣に考えていました。現在、エントリごとに辞書を使用しています (あまり効率的ではありません) が、それらに基づいてフィルター処理/並べ替えを行う実際の方法がわかりません。

4

2 に答える 2

1

OData プロバイダー内でクエリを実行しても問題ない場合は、データを T のリスト (T はエンティティの型) にロードし、list.AsQueryable() を返すだけです。これにより、クエリ可能なオブジェクトへの LINQ が返されます。これは、すべてのクエリ オプションを完全にサポートし、メモリ内ストレージ (リスト) に基づいています。これが正しく機能するには、IDataServiceQueryProvider.IsNullPropagationRequired が true を返す必要があることに注意してください (LINQ to Objects では、null がクエリを通じて正しく伝達される必要があるため)。また、CanReflectOnInstanceProperty の任意の場所を false に設定した場合は、クエリを書き直す必要があります。その場合は、この投稿を見て、プロパティへのアクセス方法について説明してください。

于 2010-04-27T19:45:22.923 に答える
0

OData の背後にいる主な意見の 1 つである Pablo Castro は、クエリ機能なしで OData サービスを提供することは、彼らの意図の範囲内で完全に一貫していると述べています。このブログ投稿を参照してください。

これは、クエリ機能が利用可能かどうかをクライアント アプリケーションが判断できるように、OData 応答に「検索」リンクを実装してほしいと強く願っている理由の 1 つです。オープンサーチのようなもの。

<Link rel="search" type="application/ODataQuery+xml" href="QueryMetadata.xml"/>

そうすれば、クライアントは検索が実装されているかどうかを簡単に確認できます。

于 2010-03-22T12:40:41.197 に答える