私はモバイル アプリケーションを持つ 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 インターフェイスを開発し、その方法で API を ajax から直接呼び出すことができます。
私の知る限り、＃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 を検討する必要があるのかということです。