1

私は思想家にブロックされているように見える演習に取り組んでいます。

任意の 2 次元の単一テーブルに適用できる ODATA サービス (クエリのみ) を作成して公開し、プログラムがテーブルのスキーマについて事前に何も知らなくても、消費者がそのテーブルをクエリできるようにしたいと考えています。

理想的には、WCF Data Services を使用したいと考えています。

1 つの考え方として、ODATA サービスは、ランダムな (ただし有効な) CSV ファイルが存在する可能性のあるファイルの場所を指し示します。そのファイルを指した場合、コンシューマーは ODATA 言語を照会して使用できる必要があります。フィルター、並べ替え、グループ化など

結合はありません。シングルテーブルです。

それについての別の考え方は、実行時まで完全に不明な DataTable であるということです。(DataSetではなく、単一の DataTable であることに注意してください。)

他の列の一意性を保証するものは何もないため、おそらく主キーは構築された列の行番号です。

これは簡単なように思えますが、新しい戦略を試すたびに壁にぶち当たります。

何かご意見は？

4

2 に答える 2

1

このユース ケースに WCF Data Services を使用すると、既存のエンティティ モデルの静的に定義された ODATA エンドポイントを簡単に作成できます。これは、通常の WCF サービスがプロデューサーとして定義した特定のサービス インターフェイスを公開するのとほぼ同じ方法です。明確にするために、これは実行時ではなくコンパイル時に定義されるスキーマです。

これ以上のことをしたい場合は、独自のカスタム プロバイダーを作成する必要がある可能性があります。そのためのさまざまな方法により、実装が徐々に難しくなるという犠牲を払って、徐々に強力な機能が提供されます。良い出発点は、ここから始まる Alex James の優れたブログ シリーズです。

http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx

明確にするために、カスタム プロバイダーの実装は非常にトリッキーであり、ニーズによっては努力する価値がない場合があります。

これを回避する 1 つの方法は、ある種のメタモデル、キーと値のペア、トリプル ストアなどを公開するデータ サービスを実装することです。どちらかのアプローチを特にお勧めします。

于 2013-07-30T13:32:01.447 に答える
1

価値のあるものとして、型のないエンティティが WebAPI 2.0 OData でサポートされるようになりました。次のブログ投稿を参照してください: http://blogs.msdn.com/b/leohu/archive/2013/11/05/typeless-entity-object-support- in-webapi.aspx

于 2013-11-26T15:38:47.943 に答える