31

ServiceStackを見たばかりで、それを使用してサービスを構築することを検討しています。

IQueryable を公開してクライアントからクエリできるように、OData フィードをサービス スタックで提供することはできますか?

4

1 に答える 1

84

編集

ServiceStackは、ODataによって促進される落とし穴やアンチパターンを回避するデータ駆動型サービスを有効にするためのアプローチである自動クエリを追加しました。

ServiceStackはODataをサポートしますか。

いいえ。

とにかく直接ではありません。ODataに値が表示された場合は、オプションのプラグインとして必要な機能を自由に追加できますが、ServiceStackコアに組み込まれることはありません。

不十分な開発慣行

ODataは、次の典型的な例と見なされる重い抽象化と「魔法の振る舞い」に激しく反対するServiceStackには適していません。

凝ったフレームワークが将来のコストを削減するために魔法のようなことをするとき、あなたが節約する毎分-あなたは10分のデバッグです。それだけの価値はありません。

ブラックボックスブロブからの魔法の振る舞いに依存することは、時の試練に耐えるとは思わない。歴史的に、これを使用するたびに（たとえば、 ADO.NET DataSets、ASP.NET Dynamic Data）、新しい開発者の慣行、パラダイム、およびサポートするように設計されていないテクノロジーは、すぐに廃止され、サポートできる新しいフレームワークが採用されました。これは、私たちが促進したくない書き直しサイクルです。

悪いWebサービス慣行を促進する

ODataはまた、サービスの内部実装の詳細を公開するアンチパターンを促進し、暗黙のサービスコントラクトを基盤となるRDBMSテーブルに緊密に結合して、将来のサービスのキャッシュ可能性、リファクタリング、またはバージョン対応を制限付きで制御できるようにします。

これは、db接続文字列を渡すのと似ています。本番環境でクライアントをバインドするとすぐに、テーブルの構造が凍結され、既存のクライアントが破損する可能性があるため、既存のDBテーブルを進化させることができなくなります。ServiceStackの推奨事項は、実装を自由にリファクタリングできる、明確に定義されたサービスレイヤーにクライアントをバインドすることです。

要約すると、ODataは確かに豊富な機能を提供しますが、個人的には、クライアントとサーバーの両方を制御および展開できるイントラネットの外部での使用はお勧めしません。

WebApiは、インターフェイスを返すことでoDataを暗黙的にサポートする最良のオプションIQueryable<T>です。

Microsoftのみのテクノロジでのみ使用されます

Web /リモートサービス（特にSOA）の主な利点の1つは、公開したい機能に対して、テクノロジーにとらわれず、相互運用可能なファサードを提供することです。ODataはオープンスタンダードですが、テクノロジ自体は基本的にMicrosoftおよび.NET関連のイニシアチブによってのみ採用されています。

ODataが遅い

OData自体は低速であることがわかり（これは私たちの主要な目的とは反対です）、実装を制御できないため、キャッシュなどのパフォーマンス向上手法をクリーンに実装することは困難です。

具体例

oDataが悪い考えである理由のコメントで具体的な例を示しました。IQueryableの最後に、 保存のためにここで繰り返すタイトカップリングの投稿があります。

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-13

なんらかの理由で既存のサービスの実装を置き換える必要がある場合（たとえば、より優れたテクノロジープラットフォームが登場した場合、実行速度が遅すぎて、このデータセットを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よりもはるかに壊れやすく、複雑で、使いにくい理由についての良い記事です。

于 2012-03-06T06:41:44.633 に答える