89

私は新しい MVC4 プロジェクトを作成しています。調査の結果、javascript からサーバー側への通信は、コントローラー アクションではなく Web API フレームワークを介して行う方が適切であると確信しています。これについて私の理解は正しいですか？

私は、Web API と MVC コントローラーの間ですべての属性などを共有できると想定しているため、一見すると、大きな変更はないようです。

アプリケーションをセットアップするとき、コンポーネントをプロジェクトに分割するのが好きです。私の計画は、MVC プロジェクトと Web API プロジェクトを持つことでした。しかし、私は問題に遭遇しました。たとえば、私は2つのアプリ自体、別のルーティング設定などになりました。

私の質問は、MVC アプリケーションでは、Web API フレームワークを同じプロジェクト内に置くべきですか、それとも Web API を独自のプロジェクトに分離して問題を回避するべきですか?

4

8 に答える 8

111

残念ながら、あなたはそれについて間違っています-私はすべての属性などをWeb apiとmvcコントローラー間で共有できると推測しているので、一見すると、それは私にとって大きな変化ではないようです。

Web APIとMVCで使用される概念の多くは、一見似ているものの、実際には互換性がありません。たとえば、Web API属性はSystem.Web.Http.Filters.Filterであり、MVC属性はSystem.Web.Mvc.Filter-であり、互換性はありません。

同じことが他の多くの概念にも当てはまります-モデルバインディング（完全に異なるメカニズム）、ルート（Web APIはルートではなくHTTPRoutesを使用しますが、両方とも同じ基になるRouteTableで動作します）、依存関係リゾルバー（互換性はありません）など-表面は、実際には非常に異なります。さらに、WebAPIには領域の概念がありません。

最終的に、達成しようとしているのがJSONコンテンツを提供する「新しい、トレンディな」方法を持つことだけである場合、その道を進む前によく考えてください。HTTPを採用し、RESTfulな方法でアプリを構築することを実際に検討しているのでない限り、既存のコードをリファクタリングすることはお勧めしません。

それは本当にあなたが何を構築しているかに依存します。新しいプロジェクトを開始する場合、必要なのはWebアプリを容易にするためにJSONを提供することだけです。ただし、重複する可能性のあるコード（上記のようなもの）を使用する場合は、WebAPIを簡単にホストできます。 ASP.NETMVCと同じプロジェクト。

オンラインサービスに適切なAPIを構築する場合（おそらく外部の顧客やさまざまなデバイスで使用される場合）、Web APIを別のプロジェクトに分離するだけです。たとえば、モバイルアプリに燃料を供給します。

于 2012-10-16T00:20:16.183 に答える
26

IMO、セキュリティ、および展開が決定を左右するはずです。たとえば、MVC アプリでフォーム認証を使用しているが、API に基本認証 (SSL を使用) を使用することに関心がある場合は、別のプロジェクトを使用すると作業が楽になります。www.example.com でサイトをホストし、API を api.example.com (vs. www.example.com/api) としてホストする場合は、別のプロジェクトを使用すると作業が楽になります。プロジェクトを分離し、それに応じてサブドメイン化し、MVC アプリから独自の API を活用する場合は、API へのクライアント側呼び出しの同一生成元ポリシーの問題に対処する方法を理解する必要があります。これに対する一般的な解決策は、jsonpまたはCORSを利用することです (できれば)。

更新 (2013 年 3 月 26 日): 正式な CORS サポートが開始されます: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

于 2012-10-16T04:59:48.210 に答える
9

ある程度の経験 (アプリと mvc の API の作成) の後。私は主に両方を行います。

他のクライアントまたは他のデバイス (Android/IOS アプリ) からの API 呼び出し用に別のプロジェクトを作成します。理由の 1 つは、認証が異なり、トークン ベースであるためです (ステートレスに保つため)。これを MVC アプリケーション内に混在させたくありません。

MVC アプリケーションへの javascript/jquery API 呼び出しについては、物事をシンプルに保ちたいので、MVC アプリケーション内に Web API を含めます。同じアプリケーション内にあるため、javascript api 呼び出しでトークンベースの認証を行うつもりはありません。[authorize]ユーザーがログインしていない場合、APIエンドポイントで属性を使用するだけで、データを取得できません。

さらに、ショッピング カートを処理し、ユーザーのショッピング カートをセッション (ログインしていない間) に保存する場合、JavaScript コードを使用して製品を追加/削除する場合は、API にもこれを含める必要があります。これにより、API が確実にステートフルになりますが、MVC-API の複雑さも軽減されます。

于 2016-02-12T12:51:01.403 に答える
6

SimpleInjector (IoC フレームワーク) の Stevenは、2 つの別々のプロジェクトについてアドバイスしています。

于 2013-04-19T09:14:11.640 に答える
2

プロジェクトが非常に複雑で 2 つの「フロント エンド」が必要な場合でも、最後の手段として webapi を別のプロジェクトに分割することを検討します。展開に頭を悩ませ、初心者がソリューションの構造を理解するのは難しいでしょう。ルーティングの問題は言うまでもありません。

system.web 名前空間を 1 つの「プレゼンテーション レイヤー」に分離しておくことを目指します。webapi はプレゼンテーション用ではありませんが、それでもアプリケーションのインターフェイスの一部です。コントローラーではなくドメインにロジックを保持している限り、あまり多くの問題に遭遇することはありません。また、エリアを利用することも忘れないでください。

于 2012-10-15T23:53:41.117 に答える
0

さらに、Web.Api 用の別の DLL をセットアップします。

ただの提案:

  1. プロジェクトを作成する
  2. ナゲット WebActivatorEx

  3. app_start で呼び出されるクラス メソッドを作成する

    [アセンブリ: WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator),"Start")]

    [assembly:WebActivatorEx.ApplicationShutdownMethod(typeof(API.AppWebActivator), "Shutdown")]

  4. Start メソッド内に web.api ルートを登録する

    public static void Start() { GlobalConfiguration.Configure(WebApiConfig.Register); }

  5. プロジェクトを Web プロジェクトに参照します。Start メソッドを有効にします。

お役に立てれば。

于 2016-02-29T06:19:29.247 に答える