apicontrollerとodataEntitySetControllerの使用
ASP.NET Web APIについて学び始めたばかりですが、まだはっきりしないことがいくつかあります。
- apiControllerの代わりにodataコントローラーから継承するEntitySetControllerを使用する必要があるのはなぜですか
- EFがODataのコンテキストで頻繁に言及されるのはなぜですか。エンティティを「表す」ことは知っていますが、2つが接続されている理由がわかりません。 1つ目はサービスレイヤーで、EFはモデルです。
- 私はこの主題について書かれた多くの文献を読んで理解しました、はい、そのベストプラクティスがいつだったか見逃しました
どうもありがとう、デビッド
apiControllerの代わりにodataコントローラーから継承するEntitySetControllerを使用する必要があるのはなぜですか
私はそれが混乱していること、そしてドキュメントが不足しているように見えることに同意します（少なくとも私があなたと同じ質問をしたとき）。私が気持ちを落ち着かせる方法は、単に コード を読むことでした。実際には非常に短いので、同じことを行うことをお勧めします（EntitySetControllerクラスとその helpers に集中してください）。トップス（約束）に5〜10分以上かかることはなく、その後は質問はありません。
短編小説は、一般的なケースの定型文をいくつか排除することです（ただし、より多くのコンテキストと意見が必要な場合は読み続けてください）。
EFがODataのコンテキストで頻繁に言及されるのはなぜですか。エンティティを「表す」ことは知っていますが、2つが接続されている理由がわかりません。 1つ目はサービスレイヤーで、EFはモデルです。
これも私を際限なく混乱させました。私が諦めてODataの起源、 WCF Data Services （以前のADO.NET Data Services）と OData仕様 （ヒントは、ODataCoreプロトコルバージョンが「DataServicesVersion」と呼ばれるヘッダーで指定されていることです。ここで、ODataは [〜＃〜] edm [〜＃〜] 、EFで使用されるのと同じモデル仕様であるエンティティデータモデルを使用し、EFと同じ形式でシリアル化することがわかります。 ： [〜＃〜] csdl [〜＃〜] （概念スキーマ定義言語）。これは偶然ではありません。WCFDataServicesはEFを主要にサポートしており、EFを必要としませんが、その設計はEFに基づいていると言えます。
WCFデータサービスに注意してください
まだですODataの主力実装でした。
潜在的に非常に興味深いもの（少なくとも私にとっては）：ASP.NET Web APIおよびOData拡張機能でEFを使用する場合、（私が知る限り）共有する方法はありません。 2つの間のモデル。
これが面白くなかった場合は、次の回答のために次の箇条書きにスキップできます。
たとえば、コードファーストのセットアップでEFを使用する場合、通常、コード規則とEF System.Data.Entity.DbModelBuilder （ "fluid API"）に主に基づいてモデルを構築します。次に、 System.Web.Http.OData.Builder.ODataConventionModelBuilder を使用します。これは、ODataモデルを構築するためにほぼ同じことを実行し、ほぼ同じ結果に到達します。過去に、私はこれについて簡単に言及したEFチームまたはWeb APIチームのいずれかからのランダムな会議からいくつかのランダムなメモを掘り起こすことができました、そして私が覚えている限り（私はもうこのドキュメントを見つけることができません）、そこに状況を改善する計画はありませんでした。したがって、EDMの2つの異なる互換性のない実装があります。
これを適切に検証するためにコードを広範囲に調べるのに時間がかからなかったことは認めますが、Web API + OData拡張機能は EdmLib （ Microsoft.Dataを提供します）に依存していることを知っています。 Edm 最初はWCF Data Services用に開発されました）が、EFは開発せず、代わりに独自の System.Data.Entity.Edm 実装を使用します。上で説明したように、彼らのコンベンションベースのモデルビルダーが異なることも知っています。 DB-FirstセットアップでEFを使用すると、ばかげたことになります。 EDMXファイル でCSDL形式のシリアル化されたEDMモデルを取得すると、OData拡張機能が続行され、EFによって生成されたCLRコード（個別のコード規則を使用）自体から実行時に独自のシリアル化されたCSDLコードが生成されます。 T4テンプレートを介して最初のCSDLから。あなたの頭は大きく回転しますか？
更新：これは 大幅に改善されました 2週間弱前（7月19日）、申し訳ありませんが、それを見逃しました。 （RaghuRam Nadimintiに感謝します。）パッチを確認しませんでしたが、サンプルコードから、EF EDMXシリアライザーを使用してモデルをCSDLにシリアル化し、EdmLibパーサーを使用して逆シリアル化する必要があるようです。 OData拡張機能によって使用されます。それでも、EFコードファーストセットアップのハックのように少し感じます（少なくとも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データサービスの非推奨 。非常に初期の話し合いでは、これを行うための「ハンドラー」、おそらくASP.NET HTTPハンドラーについて言及しています（発表に関するコメントを参照）。 ASP.NET WebAPIがWCFData Servicesのユースケースを満たすようにするためのアイデアをブレインストーミングしているため、これについてはほとんど計画が立てられていないようです。上記のユースケースについて、発表へのコメントと このスレッド （発表の数日前に開始）で説明しました。
他の多くの人々がほぼ同じ懸念を表明したので（ここでも、リンクされたディスカッションを参照）、私がこれをすべて夢見ていないのを見るのは良いことです。
ASP.NET Web APIが妥当な時間内にデータサービスのユースケースに役立つものに変わる可能性があるという不信感があるため、一部の人々は MSFTが彼らの決定を再考することを提案しました 。オープンソースの要件にASP.NETを使用するかどうかという問題も議論の余地があります。アドボカシー活動のおかげではありませんが、すべてが「うまくいく」と、WCF DataServicesはまもなくオープンソースになります。 （これは単なるソースダンプであり、この時点で誰かがそれを維持するかどうかは不明です。）
私が収集できることから、すべてが予算削減を示しており、これはすべて一粒の塩でとらえるべきですが、それは全社的な「再集中」の結果であると言う人もいます。
これらのことはさておき、時間の経過とともに新しいソリューションが出現する可能性があります。ODataAPIに関しては、WCF DataServicesやWebAPIよりもさらに優れています。今は少し混沌としているように見えますが、MSFT ODataチームは比較的早い段階で顧客からかなりのフィードバックを受け取っていたので、希望があります（特に、将来のソリューションがある場合は、それ自体がオープンソースである場合）。移行はおそらく苦痛を伴うでしょうが、将来的にはこれに関する議論を必ず見てください。
この投稿を更新するのに時間がかかるかどうかはわかりません。この答えはまだ時々賛成されているので、WebAPIとデータサービスに関する事柄が大きく変化しようとしていることを強調したかっただけです。
そして最後に、私の（個人的な）意見：ODataは、技術的にはRESTful HTTPベースのプロトコルですが、非常に、非常に、非常にデータ指向です。これはまったく問題ありません（HTTPでさまざまな種類のインターフェイスを定義できます）。たとえば、ServiceStackとODataの議論はすべて無関係です（現在の一般的なアーキテクチャでは、さまざまなレイヤーで動作すると思います）。私が心配しているのは、ODataベースのAPIを動作中心の（または「プロセス指向」または「ServiceStack」のような）APIのように動作させようとしている人々です。私にとって、OData URI規則とリソース表現形式（AtomとJSON）は一緒にSQL、WCFデータサービスを置き換えます "クエリインターセプター"と "変更インターセプター" 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コードファーストはチュートリアルで比較的簡単に表示できるため、多くのWebAPIチュートリアルではEFを使用しています。 :-)