ASP.NET Web API について学び始めたばかりですが、まだ不明な点がいくつかあります。
どうもありがとう、デビッド
ApiController の代わりに odata コントローラーから継承する EntitySetController を使用する理由
紛らわしく、ドキュメントが不足しているように見えることに同意します（少なくとも私があなたと同じ質問をしたとき）。私が気持ちを楽にする方法は、単にコードを読むことでした。非常に短いので、同じことを行うことをお勧めします (EntitySetController クラスとそのヘルパーに集中してください)。5 ～ 10 分以上かかることはありません (約束します)。その後、質問はありません。
簡単に言えば、一般的なケースのボイラープレートを削除するということです (ただし、より多くのコンテキストと意見が必要な場合は、読み続けてください)。
OData のコンテキストで EF が頻繁に言及されるのはなぜですか。それがエンティティを「表している」ことは知っていますが、2つが接続されている理由はわかりません。1 つ目はサービス層で、EF はモデルです。
これも私を際限なく混乱させましたが、あきらめて OData の起源、WCF データ サービス(以前の ADO.NET データ サービス)、およびOData 仕様(ヒントは、OData コア プロトコルのバージョンがまだヘッダーで指定されていることでした) を調べました。 "DataServicesVersion" と呼ばれます)。そこでは、OData がEF で使用されているものと同じモデル仕様であるエンティティ データ モデルであるEDMを使用し、それを EF と同じ形式である CSDL (Conceptual Schema Definition Language) でシリアル化することがわかります。これは偶然ではなく、WCF Data Services は EF を主要にサポートしており、必須ではありませんが、その設計は EF に基づいていたと言えます。
WCF Data Servicesは、依然としてOData の主力実装であることに注意してください。
関心が高い可能性があるもの (少なくとも私にとってはそうでした): ASP.NET Web API と OData 拡張機能で EF を使用する場合、(私の知る限り) 2 つの間でモデルを共有する方法はありません。
これが興味深いと思わない場合は、次の回答の次の箇条書きにスキップできます。
たとえば、Code-First セットアップで EF を使用する場合、通常は、主にコード規則と EF System.Data.Entity.DbModelBuilder ("fluid API") に基づいてモデルを構築します。次に、System.Web.Http.OData.Builder.ODataConventionModelBuilderを使用します。これは、OData モデルを構築するためにほぼ同じことを行い、ほぼ同じ結果に到達します。過去に、私は EF チームまたは Web API チームからのランダムな会議から、これについて簡単に言及したランダムなメモを何とか掘り起こすことができました。覚えている限り (このドキュメントはもう見つかりません)、そこに状況を改善する計画はありませんでした。したがって、現在、EDM の 2 つの異なる互換性のない実装があります。
これを適切に検証するために時間をかけてコードを広範囲に調べていなかったことは認めますが、Web API + OData 拡張機能はEdmLib ( WCF Data Services 用に最初に開発されたMicrosoft.Data.Edmを提供します) に依存していることを知っています。代わりに独自のSystem.Data.Entity.Edm実装を使用します。また、上記で説明したように、規約に基づくモデル ビルダーが異なることも知っています。DB-First セットアップで EF を使用するとばかげたことになります。EDMX ファイルで CSDL形式のシリアル化された EDM モデルを取得します。、および OData 拡張機能は、T4 テンプレートを介して最初の CSDL から EF によって生成された CLR コード (別のコード規則を使用) から、実行時に独自のシリアル化された CSDL コードを生成します。頭がぐるぐる回る？
更新：これは大幅に改善されました2 週間弱前 (7 月 19 日) でした。すみません、見逃してしまいました。(RaghuRam Nadiminti に感謝します。) 私はパッチをレビューしませんでしたが、サンプル コードから、EF EDMX シリアライザーを使用してモデルを CSDL にシリアル化し、EdmLib パーサーを使用してそれを逆シリアル化する必要があるようです。 OData 拡張機能によって使用されます。まだ、EF Code-First セットアップのハックのように少し感じます (少なくとも CLR コードは 1 回だけ分析されますが、最初から両方のコンポーネントが同じインメモリ モデルを使用することをお勧めします)。ただし、モデル ファーストまたはデータベース ファーストのシナリオを使用する場合は、VS によって生成された EDMX ファイルを直接逆シリアル化することで、おそらく近道を取ることができます。この最後のシナリオでは、実際にはハッキングのようには感じられませんが、繰り返しますが、単一のモデルが最適です。私はしません EF が EdmLib の使用に切り替わるか、EdmLib が EF の EDM モデルの使用に切り替わるかはわかりませんが、どちらのプロジェクトも現在非常に強力であり、ブロッカーはおそらく技術的な問題だけではありません。残念ながら、ASP.NET チームは、AFAICT について多くのことを行うことができません。
更新:これらのミーティング議事録を再びランダムに見つけました。彼らは確かに EF チームの出身であり、EdmLib に取り組む予定はないことを示しています。
しかし、今ではこれでよかったと思っています。その理由は、彼らがすべてのギャップを埋め、すべてのボイラープレートを取り除き、すべてを正しくすると、本質的に WCF Data Services が存在する場所に到達するためです。これは、プログラマーが "インターセプター」。私にとって、そこに行く唯一の理由はオープン ソースの要件のためですが、それでも、代わりにオープン ソースの WCF-DS を支持しようとする方が合理的だと思います。
ここでの質問は、「では、Web API + OData 拡張機能は何の役に立つのでしょうか?」ということになります。これは、データ ストアと Web サービスに 2 つの異なるモデルが本当に必要な場合に適しています。「インターセプター」の設計に柔軟性がなく、2 つのモデル間で変換できない場合に適しています。
更新: 2014 年 3 月 27 日の時点で公式です。彼らはこれらのギャップを埋めようとしており、その過程で WCF Data Services を非推奨にしています。非常に初期の話では、これを行うための "ハンドラー" について言及されており、おそらく ASP.NET HTTP ハンドラーです (発表のコメントを参照してください)。ASP.NET Web API で WCF Data Services のユース ケースを満たすアイデアをブレインストーミングしているため、これについてはほとんど計画が立てられていないようです。上記のユースケースについては、発表へのコメントとこのスレッド(発表の数日前に開始) で言及しました。
他の多くの人々がほぼ同様の懸念を表明しました (リンクされたディスカッションを参照してください)。
ASP.NET Web API が妥当な時間内に Data Services のユースケースに役立つものに変わる可能性があることを信じられない人もいるので、MSFT に決定を再考するよう提案する人もいます。オープン ソースの要件に ASP.NET を使用するかどうかという問題も議論の余地があります。WCF Data Services は、すべてが「うまくいけば」すぐにオープン ソース化されますが、擁護活動のおかげではありません。(これは単なるソース ダンプです。この時点で誰かがそれを維持するかどうかは不明です。)
私が収集できる限り、すべてが予算削減を示しており、これは全社的な「再集中」の結果であると言う人もいますが、これはすべて塩の粒で受け取る必要があります.
これらのことはさておき、時間の経過とともに新しいソリューションが出現する可能性があります。OData API に関しては、WCF Data Services や Web API よりもさらに優れています。現在は少し混沌としているように見えますが、MSFT OData チームは比較的早い段階で顧客からかなりのフィードバックを受け取っているため、希望があります (特に、将来のソリューションが存在する場合、それ自体がオープンソースである場合)。移行はおそらく苦痛を伴うものになるでしょうが、今後の議論に注目してください。
もうこの投稿を更新するのに時間がかかるかどうかはわかりません。この回答はまだ時々支持されているため、Web API とデータ サービスに関することが大きく変化しようとしていることを強調したかっただけです。
そして最後に、私の (個人的な) 意見: OData は、技術的には RESTful な HTTP ベースのプロトコルであるにもかかわらず、非常に非常にデータ指向です。これはまったく問題ありません (HTTP を使用してさまざまな種類のインターフェイスを定義できます)。たとえば、ServiceStack と OData の議論はすべて無関係だと思います (現在の一般的なアーキテクチャでは、それらは異なるレイヤーで動作すると思います)。私が心配しているのは、OData ベースの API を動作中心 (または「プロセス指向」、または「ServiceStack」のような) API のように機能させようとする人々です。私にとって、OData URI 規則とリソース表現形式 (Atom および JSON) は一緒に SQL を置き換え、WCF Data Services の「クエリ インターセプター」と「変更インターセプター」は DBMS トリガーとOData アクションを置き換えます。DBMS ストアド プロシージャを置き換えます。この観点から、OData API の背後に配置する必要があるドメイン ロジックが複雑すぎるか、あまりデータ指向でない場合、REST 原則を尊重しない複雑な「アクション」になってしまうことがすぐにわかります。気分が良くないエンティティ。OData API を純粋なデータ レイヤーとして扱う場合は問題ありません。SQL データベースの上に「サービス層」を置くのと同じように、その上にサービスを積み重ねることができます。
したがって、Web API + OData 拡張機能がそれほど優れているかどうかはわかりません。根本的に異なるモデルが必要な場合は、アプリケーションがデータ指向ではない可能性が高く (さまざまなソースなどからモデルを単にマージする場合を除く)、OData は適していません。これは、少なくとも Web API のみ (以下の SQL または OData のいずれか) または ServiceStack などを検討する必要がある兆候です。
良くも悪くも、Javascript クライアントは SQL をリモート サーバーと通信できません。将来的にはブラウザー API を介して、またはWebSocketsのバリアントを介して可能性がありますが、現時点では、OData は、サーバー側のロジックが薄い、またはまったくないリッチ JS クライアント用に取得されるリモート データ レイヤーに最も近いものです。もちろん、OData は他のタイプのクライアントでも使用されますが、Breeze.js や JayData のようなものが OData にとって、Entity Framework が SQL にとってどのようなものであるかを示す、クライアント側の Web プラットフォームで特に役立つと思います。
私はこの主題について書かれた多くの文献を読んで理解しました。はい、それがベストプラクティスであることを見逃していました
OData エンドポイントを作成する場合は、EntitySetController を使用します。一般的な JSON や XML、またはその他の形式 (カスタム フォーマッタを使用するなど) を返したい場合は、ApiController を使用します。
Web API では、EF と OData は必ずしも接続されていません。EF を使用しない OData エンドポイントを作成できます。EF コード ファーストはチュートリアルで比較的簡単に示すことができるため、Web API チュートリアルの多くは EF を使用します。:-)