同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか?


33

私はモバイルアプリケーションを持つMVCのプロジェクトに取り組んでいるので、モバイルアプリケーションで使用できるようにWeb APIを使用する必要があることは明らかです。

Webサイトの開発を開始したときにAPIを作成した後、私たちは混乱し、APIを使用するか、ビジネスオブジェクトに直接アクセスするかについて議論しました。そして、ビジネスオブジェクトを直接使用する代わりに、Web APIを使用する経験豊富な開発者の意見を聞いた後、私たちは終わりました。

このソリューション構造に関して混乱が生じています。

1)Web APIを使用し、HTTP要求(時間のかかる)を行って、同じソリューションにあるビジネスオブジェクトの代わりにデータを直接取得または配置する必要がある理由。

2)引数を取得した後、クライアントが別のクラウドサーバーでAPIとWebをホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合(論理的)その場合、同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか?

3)APIとWebを異なるホスティングでホストしている場合、WebはWebClientを使用し、各ナビゲーションでHTTP呼び出しを行います。正しいですか?

4)別のサーバーでAPIとWebホスティングの両方からビジネスオブジェクトを作成する場合、BLで何か変更を加えた場合は、両方のサーバーでビルドを更新する必要があります。

5)または、API用のプロジェクトを1つだけ作成し、ビューまたはhtmlページを追加してWebインターフェースを開発することで、ajaxから直接APIを呼び出すことができます。

私の知る限りでは、#5が最適なソリューションであるか、APIはサードパーティアクセス専用です。同じソリューションにDB、EF、データ層、ビジネス層がある場合、APIを使用してHTTP呼び出しを行ったり、ビジネスオブジェクトに直接アクセスしたりしないでください。(間違っている場合は修正してください)APIは、モバイルアプリケーションやデスクトップ、またはアプリケーションにアクセスしたいときに同じリポジトリとデータレイヤーを持つために必要です。

私のシナリオでは、モバイルアプリケーションもあるため、APIを作成する必要があります。プロジェクトAPI側では、ビジネスレイヤー(別のプロジェクト)と呼ばれ、ビジネスレイヤーはデータアクセスレイヤー(別のプロジェクト)と通信します。したがって、私の質問は、APIとWebを異なるサーバーにホストする場合、プロジェクトを作成してビジネスレイヤーの.dllを作成するときに、ビジネスレイヤーのメソッドを使用するよりも、HTTPリクエストであるAPIの呼び出しに時間がかかる場合があります APIコントローラーでは、ビジネスの出力をJSON形式に変換するだけです。

インターネットで検索しましたが、納得のいく答えが得られませんでした。私はブログ見つけたhttp://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspxを同じポイントを議論したが、再びそのブログで私の質問は、シナリオ#3を検討する必要がある理由です。

更新:異なるAPIプロジェクトとMVCプロジェクトを使用でき、jvascriptを使用してWebからAPIを呼び出すか、MVVMパターンを使用できます。


ビューモデルを備えたMVVMまたはMVC?
アンドリューホフマン14年

私たちは、MVC使用している
Ruchirシャー

それでは、正解はありません。APIの品質を改善する場合にのみAPIを呼び出すことには利点があります。(独自のドッグフードを食べる)また、サービスを介して呼び出すのではなく、インプロセス呼び出しを行うことでパフォーマンス上の利点があります。
アンドリューホフマン14年

Googleはこの質問に一度答えました。彼らの製品はサービスとウェブサイトの両方です。私は彼らが彼らのウェブサイトに彼ら自身のサービスを消費させることに決めたと信じています。
アンドリューホフマン14年

2
はい。Programmers.stackexchange.com/questions/148556/…およびstackoverflow.com/questions/3590561/…は優れたリソースです。ある人はそう、そうでない人もいます。本当の「正しい」方法はありません。
アンドリューホフマン14年

回答:


37

いい質問です!私は常にプロジェクトを構築するためのより良い方法を探しています。あなたが提起する各ポイントにはメリットがあり、さまざまなソリューション構造を探求しました。この種の問題に直面したときに自問するいくつかのこと:このアプリケーションはどのくらい複雑ですか?いくつのシステムを統合する必要があるか、またはこのシステムと統合する必要があるシステムはいくつですか?どの程度のテストを計画していますか?別のデザイン/ UIチームはありますか?スケールする必要がありますか?セッションを構成するものは何ですか?

少し巧妙なエンジニアリングを使用して物事を実際に成功させるいくつかのシナリオと方法を見てみましょう(そして物事を少し簡単にするいくつかのトリック)。

同じプロジェクトでAPIとWebサイトの両方をホストする
この場合、ゼロ以上のビジネスレイヤープロジェクトと単一のハイブリッドMVC / WebAPIプロジェクト(およびその他のプロジェクト-ユーティリティなど)を備えた単一のソリューションがあります。

Proの
すべてが1か所にあります。複雑なメッセージング(HttpClient呼び出し)に慣れる必要はありません。共有セッション状態(Cookie、InProc / OutOfProcセッションなどによるクライアントとサーバー)、接続プーリング、共有ロジックなどを使用できます。 。展開はこれ以上簡単ではありません。

Con's
Everythingは1か所にあります。これはおそらく最もモノリシックな構造です。あなたの層の間に定義されたインタフェースは一切明らかにありません..あなたは、で終わる高凝集。怠け者の開発者は、この種のアーキテクチャを扱う際に、テストを非常に苦痛にするインターフェースを避けます。アプリケーションのスケーリング/コロケーションは困難です。

用途
このプロジェクト構造は、1回限りの、内部、または単純なアプリケーションに使用します。地元のYでのバスケットボールキャンプの申し込みを追跡するための迅速なシステムを構築していますか?これがあなたのアーキテクチャです!

異なるプロジェクトのWebAPIとWebサイト
このケースを好む傾向があります。1つ(またはそれ以上)のMVCプロジェクトと1つのWebAPIプロジェクトで単一のソリューションがあります。

Proの
モジュール化! ゆるい結合!各プロジェクトは独立してテストでき、個別に管理できます。これにより、ニーズに応じてさまざまなキャッシュ戦略をより簡単に実装できます。異なるシステム間で強固な境界を保つことにより、特定の使用パターンを強制し、起こりうる摩擦を削減できる契約をより簡単に確立できます(読む:バグを減らし、APIを悪用する機会を減らします)。高負荷が発生しているビットのみをスケーリングする必要があるため、スケーリングは少し簡単です。APIが最初からどのように見えるかについてのアイデアが必要になるため、統合の処理も少し簡単になります。

Conの
保守はもう少し難しいです。複数のプロジェクトは、マージ、契約(インターフェイス)、展開などを追跡するためにプロジェクト/機能の所有者が必要になることを意味します。コードの維持、技術的負債、エラー追跡、状態管理-これらはすべて、異なるベースあなたのニーズに応じて。これらの種類のアプリケーションは、成長に合わせて最も計画とキュレーションも必要とします。

用途
100人のユーザー、今日10万来週/月を持っている可能性がアプリケーションを構築しますか?アプリケーションは通知を送信し、複雑なワークフローを管理し、複数のインターフェイス(Web +モバイルアプリ+ SharePoint)を持っている必要がありますか?週末に5000以上のピースパズルを解くのが好きですか?これはあなたのためのアーキテクチャです!

ヒント
上記の概要を説明したので、次のプロジェクトがいかに困難なものになるかを理解できます。心配する必要はありません、ここに私が長年にわたって学んだいくつかのトリックがあります。

  1. ステートレスセッションを使用してみてください。小規模なシステムでは、これは、少なくとも現在のユーザーの内部IDとタイムアウトを含む暗号化されたCookieを保存することを意味する場合があります。大規模なシステムでは、データストア(Redisの、テーブル記憶からフェッチされたかもしれない簡単なセッションIDと暗号化されたCookie保存意味するかもしれませんDHTあなたがそのようあなたが十分な情報を格納することができた場合は...、など)をしていない主なデータベースをヒットする必要がありすべてのリクエストで、あなたは良い場所にいます-しかし、クッキーを1k未満に保つようにしてください。
  2. おそらく複数のモデルが存在することに注意してください。モデルと予測の観点から考えてみてください(ここで見つけたリンクは良くありませんでした。考えてみてください。ある男性の在庫品目は別の男性の注文品目です-基本的な構造は同じですが、異なるビューです)。一部のプロジェクトには、論理的/概念的な境界ごとに異なるモデルがあります(つまり、特定のAPIとの通信に特定のモデルを使用します)。
  3. APIはどこでも!オブジェクト/クラス/構造がデータまたは動作を公開するときはいつでも、APIを確立しています。他のエンティティまたは依存関係がこのAPIを使用する方法に注意してください。このAPIをテストする方法について考えてください。このAPIと通信しているもの(コードを介した他のオブジェクト?プロトコルを介した他のシステム?)とそのデータの公開方法(強く型付けされたJSON?*咳* XML?)を考慮してください。
  4. 今から2年後になると思っているものではなく、あなたが持っているもののために構築してください。別の答えはYAGNIを参照しています-それらは絶対に正しいです!架空の問題を解決すると、締め切りが架空になります。反復のための堅実な目標を設定し、それらを達成します。デプロイ!開発中のプロジェクトは、ユーザーが1人だけのプロジェクトです-あなた!
  5. YMMV(マイレージは異なる場合があります)。ここには絶対的なものが1つしかありません。問題があり、解決策を構築しています。他のすべては完全に空中にあります。上記の両方のソリューションは、大きな成功を収めることができます。それはすべてあなた、あなたのツール、そしてあなたがそれらをどのように使用するかによります。開発者仲間!

2
素晴らしい答えです!あなたの執筆に対して何か賞を授与できるといいのですが、何も考えられないので、私はあなたのTwitterをフォローします。:P
ダン

「強く型付けされましたか?JSON?*咳* XML」何が欠けていますか?
アレクサンダー・ダーク

1
@AlexanderDerck私は3つの異なるフォーマットオプションについて言及しています(もっとありますが)。「ジョーク」は、XMLを扱うのが難しく、しばしばかなりのオーバーヘッド(シリアライゼーション/デシリアライゼーション)を追加する可能性があることです。それは、(外部グループで作業する場合は特に)、時には必要がないと言っているわけではない...
ボビーD

6

ビジネスオブジェクトに直接アクセスすること(コントローラーを意味していると思います)が、より速く簡単になります。

クライアントが別のクラウドサーバーでAPIとWebをホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合(多少論理的)

次に、それらを個別にホストする必要があります...しかし、それは私には非常に論理的に聞こえません、確かに両方をスケーリングしたいと思うでしょう。この要件を満たす必要がありますか?それはやり過ぎのように聞こえます。YAGNIを覚えておいてください-必要なければ、ビルドしないでください。必要なときにビルドします。

私なら、サイトに最適な技術を使用してサイトを構築し、(必要な場合)他の人が呼び出すことができるサービスが必要な場合、それを個別に構築します。


日の終わりにはスケーリングが重要であり、懸念の分離は私にとって重要であるため、私はあなたに完全に同意します。n層アーキテクチャを、簡単にアップグレードまたは保守できる技術の変更として構築することを考えるのは常に良いことです。たとえば、Dockerコンテナでのラップは、今後検討すべきもう1つの事項です。
イシュウォルカナル

4

私は言うだろう。HTTPClientを介してWebAPIを呼び出すMVCを好みます。「コアdll」ロジックを回避するのは圧倒的ですが、主な利点は、システム全体がHTTP上のドメインオブジェクトにシングルポイントでアクセスできることです...とにかく、Micro Service Architectureのピックアップとアプリの切り替えクライアントサイドフレームワーク(AngularJSなど).... MVCを別のクライアントとして扱う方が良い...そして、APIをうまく管理するためにチームを弟子にする...

シンプルに。この助けを願っています。ありがとう。


これがなぜ反対票を投じられたのか
定か

私は自分のMVCアプリからAPIを呼び出すのは良い考えだと思った私の状況について考えていましたが、これとは異なり、サーバーロジックからこの呼び出しを参照する他の多くの質問もあると思います。私の場合、Vueが複雑なUIを形成し、そのAPIにデータを渡すようにするビューから実際に呼び出します。私の場合、実際にはビューから呼び出すこととサーバー側のアイテムであり、任意の種類のUIを検討するときにHTTP呼び出しが行われたので、ASPで作成されたビューの場合はさらにそうです。ただし、JS環境でのみ機能します。
ヴァシリーホール

ビュー呼び出しAPIを直接使用することをお勧めします。ただし、MVCビューはサーバーから生成されるため、部分ビュー(ビュー)をレンダリングする前に、特にサーバー処理に関連するサーバーからのデータを処理することもできます... RESSフレームワーク(RESS :レスポンシブWebデザイン+サーバー側コンポーネント)....ただし、MVCを完全に回避できる場合は、Pureクライアントフレームワーク(Angular / ReactJS)を最適に使用してください...
Manoj Kumar Bisht
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.