MVC4 + Entity + WebAPI を初めて使用したので、単純に GET、POST コントローラー ハンドラー、およびデータ モデルへのカスタム マッピングが必要であることに不満を感じていました。
たとえば、データクラスからコントローラークラスを作成して、データから簡単なGETコマンドを実行できるようにするための生成ツールはありますか?
コマンドをそのまま作成できるように、一般的なRESTful APIを作成するアプローチは何ですか
GET api/1.0/{genericdatatype}/{id}
一般的なデータ型は、特定のコントローラーではなく、任意のモデルにすることができますか? PUT (MVC アプリを介して処理される) は必要ないので、POST 検証などは実際には必要ないとします。
モデルに基づいてコントローラーを構築する MVC Scaffolding と呼ばれるツール/パッケージがあります。
http://mvcscaffolding.codeplex.com/
一般的な部分に関しては、それは非常に長く困難なプロセスであり、かなりの時間がかかります. 誰かがそれに対する良い答えを持っているなら、それも見てみたいです。
編集：一般的な部分を調べるために、さらに時間を費やしました。他の誰かが同様の考えを持っていて、ここでほぼ同じ質問をしたようです: Generic Web Api controller to support any model。
結局のところ、彼らはその会話の中でいくつかの優れた懸念を表明しています. さまざまな種類の ID をどのように処理しますか? それらは常に文字列である必要があり、その後解析されるのでしょうか? さらにビジネス ルールを理解すると、コントローラーの背後に非常に複雑なビジネス レイヤーが存在するのではないかと思います。とはいえ、一般的な API を構築するよりも、単純な足場に固執する方がよいと思います。確かに、それはおそらく実行できますが、API の背後にあるクレイジーな解析コードと時間のコストはどれくらいでしょうか? ちょうど私の考え。
私たちのチームが採用した代替案を私自身が提供しています。OData。CRUD よりもクエリに重点を置いて初期の RESTful テンプレートを作成するための簡単な方法であり、手動でエンドポイントを構築する必要なくデータを利用できるようにします。私は現在、Web API サーバー上に OData を持つプロジェクトのフロント エンドを行っています。これは、コレクション エンドポイントよりも差し迫った問題に取り組むバックエンド開発者を解放するために見事に機能します。
Entity フレームワークでも動作します。