動的オブジェクトに対して既存のlinqクエリを実行する（Datatableのように）

Question

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

私の問題は、ODATAがクエリをサポートし、私がiQueryable実装を手渡すことを期待していることです。ロウサイドでは、クエリサポートはありません。冗談ではありません - プロバイダーはテーブルを返し、Where句はサポートされていません。ここではパフォーマンスは問題ではありません - テーブルは小さいです。 ODATAプロバイダーに並べ替えても構いません。

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

• テーブルのデータを取得するためにSQLステートメントを提出します。結果は、ここにある種のADO.NETデータリーダーのようなものです。
• このデータのiQueryable実装を公開して、後でフィルタリングを可能にする必要があります。

それを最もよく触れる方法はありますか？ .NET 3.5のみ（しばらくの間4.0が計画されていません）。私は、すべてのテーブル（bytecodeを放出する）の動的DTOクラスを作成することを真剣に考えていたので、標準のLINQを使用できます。現在、私はエントリあたりの辞書を使用しています（あまり効率的ではありません）が、それらに基づいてフィルタリング /ソートする本当の方法はありません。

Answer 1

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

これは、クライアントアプリケーションがクエリ機能が利用可能かどうかを判断できるように、ODATA応答に「検索」リンクを実装したい理由の1つです。 OpenSearchのようなもの。

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

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

Answer 2

ODATAプロバイダー内のクエリを実行しても大丈夫なら、データをTのリスト（Tのタイプのタイプ）に単純にロードしてから、list.asqueryable（）を返すだけです。これにより、LINQがオブジェクトクエリに戻ります。これは、すべてのクエリオプションを完全にサポートし、メモリ内のストレージ（リスト）に基づいています。これが正しく機能するためには、idataservicequeryprovider.isnullpropagationrequiredがtrueを返す必要があることに注意してください（linqがクエリを通じてヌルを正しく伝播する必要があるため）。また、CanreflectonInstancePropertyをどこにでもfalseに設定すると、クエリの書き換えを行う必要があります。その場合はこの投稿を見てください ここ プロパティがどのようにアクセスされるかについての説明。