同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか？
私は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パターンを使用できます。
すばらしい質問です。私は常にプロジェクトを構造化するためのより良い方法を探しています。あなたが提起する各ポイントにはメリットがあり、さまざまなソリューション構造を検討した結果、ここでのコメントの大部分に同意する必要があります。完璧なソリューションはありません。この種の問題に直面したときに自問すべきことがいくつかあります。このアプリケーションはどのくらい複雑ですか？統合する必要のあるシステムの数-または、このシステムと統合する必要のあるシステムの数は？どのくらいのテストを行う予定ですか？別のデザイン/ UIチームはありますか？スケーリングする必要がありますか？セッションとは何ですか？
いくつかのシナリオと、少し巧妙なエンジニアリングを使用して物事を本格的にする方法（および物事を少し簡単にするためのいくつかのトリック）を見てみましょう。
同じプロジェクトでのAPIとWebサイトの両方のホスティング
この場合、0個以上のビジネスレイヤープロジェクトと単一のハイブリッドMVC/WebAPIプロジェクト（およびその他のプロジェクト-ユーティリティなど）を含む単一のソリューションがある場合があります。
プロの
すべてが1か所にあります。複雑なメッセージング（HttpClient呼び出し）で一気に行う必要はなく、共有セッション状態（Cookieを介したクライアントとサーバー、InProc/OutOfProcセッションなど）、接続プーリング、共有ロジックなど。展開はこれ以上簡単にはできません。
短所
すべてが1か所にあります。これは、おそらく最もモノリシックな構造です。レイヤー間に明確に定義されたインターフェースはありません。最終的には high-cohesion になります。怠惰な開発者は、このタイプのアーキテクチャを扱うときにインターフェイスを避け、テストを非常に困難にします。アプリケーションのスケーリング/共存は困難です。
用途
このプロジェクト構造は、1回限りの、内部の、または単純なアプリケーションに使用します。地元のYでバスケットボールキャンプの登録を追跡するための迅速なシステムを構築していますか？これがあなたの建築です！
異なるプロジェクトのWebAPIとWebサイト
私はこのケースを好む傾向があります。1つの（または複数の）MVCプロジェクトと1つのWebAPIプロジェクトを使用する単一のソリューションがあります。
プロの
モジュール化！ルーズカップリング！ 各プロジェクトはスタンドアロンで、個別にテストされ、異なる方法で管理できます。これにより、ニーズに応じて異なるキャッシュ戦略をより簡単に実装できます。異なるシステム間でしっかりした境界を維持することで、特定の使用パターンを適用し、起こりうる摩擦を減らすことができる契約をより簡単に確立できます（読み取り：バグを減らし、APIを悪用する機会を減らします）。高負荷のビットのみをスケーリングする必要があるため、スケーリングは少し簡単です。 APIが最初からどのように見えるかを理解する必要があるため、統合も少し扱いやすくなります。
短所
メンテナンスはもう少し難しいです。複数のプロジェクトとは、マージ、契約（インターフェース）、デプロイメントなどを追跡するためにプロジェクト/機能の所有者が必要になることを意味します。コードの維持、 技術的負債 、エラー追跡、状態管理-すべてが懸念事項になります。ニーズに応じて異なる方法で実装する必要がある場合があります。これらの種類のアプリケーションも、成長に応じて最も計画とキュレーションが必要です。
用途
今日100人のユーザーがいて、来週/月に100,000人のユーザーがいるアプリケーションを構築していますか？アプリケーションは通知を送信し、複雑なワークフローを管理し、複数のインターフェイス（Web +モバイルアプリ+ SharePoint）を備えている必要がありますか？週末にたくさんの時間を過ごし、5000以上のピースパズルを解くのが大好きですか？これはあなたのためのアーキテクチャです！
ヒント
上記の概要を説明したので、次のプロジェクトが少し困難に見えるかもしれません。心配しないで、ここに私が長年にわたって学んだいくつかのトリックがあります。
- ステートレスセッションを使用してみてください。小規模なシステムでは、これは、少なくとも現在のユーザーの内部IDとタイムアウトを含む暗号化されたCookieを保存することを意味する場合があります。大規模なシステムでは、データストア（redis、テーブルストレージ、 [〜＃〜] dht [〜＃〜] など）からフェッチされる可能性のある単純なセッションIDで暗号化されたCookieを保存することを意味する場合があります。十分な情報を保存できるので、すべてのリクエストでメインデータベースにアクセスする必要がない必要はありません。そうすると、適切な場所に移動できますが、Cookieを1k以下に保つようにしてください。
- おそらく複数のモデルがあることに注意してください。モデルと予測の観点から考えてみてください（ここで見つけたリンクは良くありませんでした。考えてみてください：ある男性の在庫項目は別の男性の注文品目です-基本的な構造は同じですが、ビューが異なります）。一部のプロジェクトでは、論理的/概念的な境界ごとに異なるモデルがあります（つまり、特定のAPIとの通信に特定のモデルを使用しています）。
- APIはどこにでもあります！オブジェクト/クラス/構造がデータまたは動作を公開するときはいつでも、APIを確立しています。他のエンティティまたは依存関係がこのAPIをどのように使用するかに注意してください。このAPIをテストする方法を考えてください。このAPI（コードを介した他のオブジェクト？プロトコルを介した他のシステム？）と何が話しているか、そのデータがどのように公開されているか（強く型付けされている？JSON？*咳* XML？）を検討してください。
- あなたが今持っているもののために構築し、あなたがあなたが今から2年持つと想像するものではない。別の回答の参照 [〜＃〜] yagni [〜＃〜] -それらは完全に正しいです！架空の問題を解決すると、締め切りが架空になります。イテレーションの確実な目標を設定し、それらを満たします。デプロイ！開発中のプロジェクトは、ユーザーが1人だけのプロジェクトです-あなたです！
- [〜＃〜] ymmv [〜＃〜] （マイレージは異なる場合があります）。ここには絶対的なものは1つしかありません。問題があり、ソリューションを構築しています。それ以外はすべて完全に空中になっています。上記の両方のソリューションは、大成功を収めることができます-そして、吸引の失敗。それはすべてあなた、あなたのツール、そしてあなたがそれらをどのように使うか次第です。軽くトレッド、仲間の開発者！
ビジネスオブジェクトに直接アクセスする（コントローラーで意味することを想定しています）と、より速く簡単になります。
クライアントがAPIとWebを別のクラウドサーバーでホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合（これはやや論理的）
次に、それらを個別にホストする必要があります...しかし、それは私にはあまり論理的に聞こえません。確かに、両方をスケーリングする必要があります。この要件を満たす必要がありますか？それはやり過ぎのように聞こえます。 YAGNIを覚えておいてください-必要なければ、構築しないでください。必要なときにビルドします。
それが私であれば、サイトに最適なテクノロジを使用してサイトを構築し、他の人が呼び出すことができるサービスが必要な場合は、それを個別に構築します。
私は言うでしょう; MVCがHTTPClientを介してWebAPIを呼び出すことを好む。それは「コアdll」ロジックを圧倒しますが、主な利点は、システム全体がHTTP上のドメインオブジェクトにシングルポイントでアクセスできることです。クライアント側フレームワーク（AngularJSなど）... MVCを別のクライアントとして扱う方がよい...そして、APIを適切に管理するためにチームを訓練する...
シンプルに保つ。この助けを願っています。ありがとう。