ServiceStackを使用したOData？
ServiceStack を見たばかりで、それを使ってサービスを構築することを検討しています。
IQueryableを公開してクライアントからクエリできるように、サービススタックでODataフィードを提供することは可能ですか？
編集
ServiceStackは、 自動クエリ を追加しました。これは、データ駆動型サービスを有効にするためのアプローチであり、 ODataによって促進される落とし穴とアンチパターン を回避します。
ServiceStackはODataをサポートしますか。
番号。
とにかく直接ではありません。 ODataに値が表示された場合は、必要な機能をオプションとして自由に追加できます プラグイン -ただし、ServiceStackコアに組み込まれることはありません。
貧弱な開発慣行
ODataは、 重い抽象化に激しく反対する および 典型的な例 と見なす「魔法の振る舞い」を行うServiceStackには適していません。
凝ったフレームワークが将来のコストを削減するために魔法のようなことをするとき、あなたが節約する毎分-あなたは10分のデバッグです。それだけの価値はありません。
ブラックボックスブロブからの魔法の振る舞いに依存することは、時の試練に耐えるとは思わない。歴史的に、これを使用するたびに（たとえば、 ADO.NET DataSets 、 ASP.NET Dynamic Data ）、これらのフレームワークに固有の柔軟性のない制限にすぐに遭遇しました。は、サポートするように設計されていない新しい開発者のプラクティス、パラダイム、およびテクノロジーをサポートするように進化することができないため、サポートできる新しいフレームワークを優先してすぐに非推奨になります。これは、私たちが促進したくない書き直しサイクルです。
悪いWebサービス慣行を促進する
ODataは、サービスのアンチパターンも促進します内部実装の詳細を公開暗黙のサービスコントラクトを基盤となるRDBMSテーブルに緊密に結合し、キャッシュ可能性、リファクタリング、またはバージョンの制御を制限します-将来のあなたのサービスの能力。
これは、db接続文字列を渡すのと似ています。本番環境でクライアントをバインドするとすぐに、テーブルの構造が凍結され、既存のクライアントが破損する可能性があるため、既存のDBテーブルを進化させることができなくなります。 ServiceStackの推奨事項は、実装を自由にリファクタリングできる、明確に定義されたサービスレイヤーにクライアントをバインドすることです。
要約すると、ODataは確かに豊富な機能を提供しますが、個人的には、クライアントとサーバーの両方を制御および展開できるイントラネットの外部での使用はお勧めしません。
WebApiは、IQueryable<T>インターフェースを返すことでoDataを暗黙的にサポートする最良のオプションです。
Microsoftのみのテクノロジでのみ使用されます
Web /リモートサービス（特にSOA））の主な利点の1つは、公開したい機能に対してテクノロジーにとらわれず、相互運用可能なファサードを提供することです。ただし OData はオープンスタンダードであり、テクノロジー自体は基本的にMicrosoftと 。NET関連のイニシアチブ によってのみ採用されています。
ODataが遅い
OData それ自体が遅いことがわかりました （これは私たちのコア目標とは反対です）そして実装に対する制御の欠如は、それをキャッシュするようなパフォーマンス向上技術をきれいに実装することを困難にします。
具体例
IQueryable is Tight Coupling の投稿の最後に、oDataが悪い考えである理由のコメントで具体的な例を示しました。これは、保存のためにここで繰り返します。
Webサービスインターフェイスの全体的な考え方は、テクノロジーにとらわれない相互運用可能なAPIを外部に公開することです。
IQueryable/ODataエンドポイントを公開すると、既存のクライアントがバインドされている「クエリスペース」、つまりフリーズ/サポートする必要のある既存のクエリ/テーブル/ビュー/プロパティを無期限に特定できないため、サービスをODataの使用に効果的に結合します。これは、APIの表面領域で実装を公開するときに問題になります。これは、APIに独自のカスタムロジックを追加する機能が制限されるためです。承認、キャッシュ、監視、レート制限など。また、ODataは非常に遅いため、パフォーマンス/スケーリングの問題が早期に発生します。エンドポイントを制御できないということは、事実上書き換えに向かっていることを意味します： https://coldie.net/?tag=servicestack
NetflixのODataAPIからの既存のクエリを見て、oDataプロバイダーの実装から移行することがどれほど実現可能かを見てみましょう。
http://odata.netflix.com/Catalog/Titles ？$ filter = Type％20eq％20'Movie '％20and％20（Rating％20eq％20'G'％20or％20Rating％ 20eq％20'PG-13 '）
このサービスは、「タイプ」と呼ばれる列を持つ「タイトル」と呼ばれるテーブル/ビューに効果的に結合されています。
また、ODataを使用していなかった場合、どのように自然に記述されるでしょうか。
http://api.netflix.com/movies?ratings=G,PG-1
なんらかの理由で既存のサービスの実装を置き換える必要がある場合（たとえば、より優れたテクノロジープラットフォームが登場した場合、実行が遅すぎて、このデータセットをNoSQL/Full-TextIndexingに裏打ちされたslnに移動する必要があります）どのくらいの労力が必要ですかOData impl（RDBMSスキーマとODataバイナリimplに効果的にバインドされている）を、以下のより直感的なimplに依存しないクエリに置き換える必要がありますか？不可能ではありませんが、新しいテクノロジーにOData APIを実装することは非常に難しいため、既存のクライアントを書き換えて壊すことが好ましいオプションになる傾向があります。
内部の実装に外部向けのURL構造を指示させることは、状況を変更する必要があるときに既存のクライアントを壊す確実な方法です。これが、Cool URIの背後でサービスを公開する必要がある理由です。つまり、サービスのテクノロジーの選択を制限したくないため、変更されない論理的な永続URL（実装によって妨げられない）です。
アドホックな「探索サービス」を提供したい場合は良いオプションかもしれませんが、本番システムで外部クライアントをバインドしたいとは思わないでしょう。また、その使用をローカルイントラネットのみに制限する場合、読み取り専用の接続文字列を提供するだけでなく、どのような利点がありますか？これにより、他の人がお気に入りのSql Explorer、Reporting、またはSQLを話すその他のツールで使用できるようになります。
更新
Netflixはちょうど 2013年4月8日に発効したODataカタログを廃止 。
リモートサービスを定義するためにクリーンで明確に定義された汚染されていないDTOを使用することをお勧めする理由 に新しい回答を追加しました。これは、ODataの使用が促進しないリモートサービスのベストプラクティスです。
理由に関する良い記事 ODataのような汎用ベースのAPIは、同等のインテントベースのAPIよりもはるかに壊れやすく、複雑で、使いにくい 。