私は新しいMVC4プロジェクトを作成しています。研究により、コントローラーアクションよりも、Web APIフレームワークを使用して、JavaScriptからサーバー側への通信がよりよく達成されると信じるようになりました。これについての私の理解は正しいですか?
私はすべての属性などをWeb APIとMVCコントローラー間で共有できると考えているので、一見すると、それは私にとって大きな変化ではないようです。
アプリケーションをセットアップするとき、コンポーネントをプロジェクトに分割するのが好きです。私の計画は、MVCプロジェクトとWeb APIプロジェクトを持つことでした。しかし、私は問題に突き当たりました。たとえば、2つのアプリ、別々のルーティングのセットアップなどになりました。
ですから、私の質問は、MVCアプリケーションでは、Web APIフレームワークを同じプロジェクト内に配置する必要がありますか、それともWeb APIを独自のプロジェクトに分割して問題を回避する必要がありますか?
残念ながらあなたはそれについて間違っています-Web APIとMVCコントローラ間ですべての属性などを共有できると考えているので、一見すると、それは私にとって大きな変化ではないようです
Web APIとMVCで使用される概念の多くは、一見似ていますが、実際には互換性がありません。たとえば、Web API属性はSystem.Web.Http.Filters.Filter
およびMVC属性はSystem.Web.Mvc.Filter
-そして、それらは互換性がありません。
同じことが他の多くの概念にも当てはまります-モデルバインディング(完全に異なるメカニズム)、ルート(Web APIはルートではなくHTTPRoutesを使用しますが、両方とも同じRouteTableで動作します)、依存関係リゾルバー(互換性なし)など-表面は、実際には非常に異なっています。さらに、Web APIにはエリアの概念がありません。
最終的に、達成しようとしているのがJSONコンテンツを提供する「新しい、トレンディな」方法を持つことだけである場合、その道を進む前によく考えてください。本当にHTTPを採用し、RESTfulな方法でアプリを構築することを真剣に検討しているのでなければ、既存のコードをリファクタリングすることはお勧めできません。
それは本当にあなたが構築しているものに依存します。新しいプロジェクトを開始する場合、必要なのは、Webアプリを容易にするためにJSONを提供することだけです-重複する可能性のあるコード(上記のようなもの)を使用する場合は、Web APIを簡単にホストできますASP.NET MVCと同じプロジェクト。
外部アプリやモバイルアプリに燃料を供給するなど、さまざまなデバイスによって消費されるオンラインサービスに適切なAPIを構築する場合にのみ、Web APIを個別のプロジェクトに分離します。
IMO、セキュリティ、および展開があなたの決定を後押しするはずです。たとえば、MVCアプリでフォーム認証を使用しているが、APIに基本認証(SSLを使用)を使用することに関心がある場合、別のプロジェクトで作業が楽になります。 www.example.comでyoutサイトをホストするが、api.example.com(vs. www.example.com/api)としてAPIをホストする場合は、個別のプロジェクトで作業が楽になります。プロジェクトを分離し、それに応じてサブドメイン化し、MVCアプリから独自のAPIを活用する場合、クライアント側の呼び出しに対する Same Origin Policy の問題に対処する方法を理解する必要がありますAPI。これに対する一般的な解決策は、 jsonp または [〜#〜] cors [〜#〜] (できればできれば)を活用することです。
更新(2013年3月26日):公式のCORSサポートが予定されています: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
ある程度の経験(アプリおよびmvc用のAPIの作成)。私は主に両方を行います。
私は、他のクライアントまたは他のデバイス(Android/IOSアプリ)からのAPI呼び出し用に個別のプロジェクトを作成します。その理由の1つは、認証が異なるため、トークンベースであるためです(ステートレスを維持するため)。 MVCアプリケーション内でこれを混在させたくありません。
私のmvcアプリケーションへのjavascript/jquery api呼び出しについては、MVCアプリケーション内にweb apiを含めるために、物事をシンプルに保つのが好きです。私はjavascript api呼び出しでトークンベースの認証を行うつもりはありません。なぜなら、それは同じアプリケーション内にあるからです。 APIエンドポイントで[authorize]
属性を使用できます。ユーザーがログインしていない場合、ユーザーはデータを取得しません。
さらに、ショッピングカートを処理し、ユーザーのショッピングカートを(ログインしていない状態で)セッションに保存する場合、javascriptコードを介して製品を追加/削除する場合も、これをAPIに含める必要があります。これにより、APIが確実にステートフルになりますが、MVC-APIの複雑さも軽減されます。
SimpleInjector(IoCフレームワーク)のStevenは、2つの個別のプロジェクトにアドバイスしています: WebAPIのDependencyResolver.SetResolverとHttpConfiguration.DependencyResolverの違いは何ですか?
最近、ほぼ同じことを行いました。VS2012でWeb APIテンプレートを選択する新しいMVC 4 Webアプリケーションプロジェクトから始めました。
これにより、MVCと同じアプリケーションでホストされるWeb APIが作成されます。
ApiControllersを別のクラスライブラリプロジェクトに移動したかった。これはかなり簡単でしたが、解決策は少し隠されていました。
MVC 4プロジェクトのAssemblyInfo.csに、同様のコード行を追加します
[Assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
ここで、クラスLibraryRegistratorが必要です(名前は自由に付けてください)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
MVC 4プロジェクトでは、Apiライブラリへの参照も追加します。
これで、Apiコントローラーを独自の個別のクラスライブラリ(yourown.dll)に追加できます。
プロジェクトが2つの「フロントエンド」を保証するほど複雑な場合でも、最後の手段としてwebapiを個別のプロジェクトに分割することだけを検討します。展開に頭痛があり、初心者がソリューションの構造を理解することは困難です。ルーティングの問題は言うまでもありません。
System.web名前空間を1つの「プレゼンテーションレイヤー」に分離したままにすることを目指します。 webapiはpresentationalではありませんが、アプリケーションのインターフェースの一部です。コントローラではなくドメイン内にロジックを保持している限り、多くの問題に遭遇することはないはずです。また、エリアを使用することを忘れないでください。
APIコントローラーを新しいプロジェクトに分割しようとしました。私がしたことは、新しいライブラリプロジェクトを作成し、コントローラをAPIという名前のフォルダ内に移動することだけです。次に、ライブラリプロジェクトの参照をMVCプロジェクトに追加しました。
WebAPI構成は、MVCプロジェクト自体に残ります。正常に動作します。
Web.Apiの個別のDLL。
単なる提案:
App_startで呼び出されるクラスメソッドを作成します
[アセンブリ:WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator)、 "Start")]
[Assembly:WebActivatorEx.ApplicationShutdownMethod(typeof(API.AppWebActivator)、 "Shutdown")]
Startメソッド内にweb.apiルートを登録する
public static void Start(){GlobalConfiguration.Configure(WebApiConfig.Register); }
プロジェクトをWebプロジェクトに参照します。 Startメソッドをアクティブにします。
お役に立てれば。