Webおよびモバイルクライアントのアーキテクチャ
私が取り組んでいるアプリケーションには、Webインターフェイス（ASP.NET MVC）とモバイルインターフェイス（Android/IPhoneネイティブ）が必要です。モバイルアプリケーションとWebアプリケーションの機能は重複しない場合があります（一部の機能は類似しており、一部は異なる）
現在、私は以下のようにアプリケーションを構成する2つの方法を考えています。
トップアプローチの場合、Webクライアントとモバイルクライアントの両方を処理する1つのWebサーバーが必要です。モバイルはJsonを介してサーバーと通信します（ASP.NET MVCによってシリアル化されます）。サービスレイヤーは、Webレイヤーで参照されるプレーンクラスライブラリです
- 長所
- Webレイヤーとサービスレイヤーの間にマシン間通信がないため、より高速
- よりシンプル
- 短所
- セキュリティ？ここでセキュリティ上の懸念はありますか？
- スケーリングの柔軟性が低くなります（Webレイヤーとサービスレイヤーの両方を1つのユニットとしてのみスケーリングできます）。
ボトムアプローチの場合、1つのWebサーバーと1つのアプリケーションサーバー（WCF/Web API用）が必要です。モバイルは、Jsonを介してアプリケーションサーバーと直接通信します。
- 長所
- Webサーバーとアプリケーションサーバーを別々に保護できます。アプリケーション層に追加の保護層があります。しかし、アプリケーションサーバーはモバイルに公開されています。
- Webサーバーとアプリケーションサーバーを個別にスケーリングできます
- 短所
- もっとゆっくり
- 途中にWCF/Web APIがあるため、さらに複雑になる
このようにWebとモバイルの両方でアプリケーションを実行するのは初めてです。このシナリオで一般的に使用されるアプローチはどれですか？ユーザーはボトムアプローチを好む傾向がありますが、この場合、ボトムアプローチに従うのはやり過ぎかもしれません。
私が目にする主な問題はトップアプローチを使用、websiteがモバイルからのリクエストを受け入れることができる必要があるということです、サービスとは対照的に。それはウェブサイトが心配する必要のないもののようです。特に、それはWebサイトにサービスのAPIを複製するための一連の「パススルー」ロジックがあるか、またはWebサイトがサービスのAPIとは異なるAPIを提供している（おそらく少し両方の）。いずれにしても、それは保守性の大きな問題です。さらに、サービスと直接通信する場合と比較して、モバイルリクエストがジャンプするためのハードル（および潜在的なボトルネック）が1つ追加されます。
それぞれの場合に1つまたは2つのサーバーが必要であるという主張は、正反対の問題です。必要に応じて、Webサイトとそのサービスを同じサーバーに配置できます（私はこれを何度も行っています）。それを行うかどうかは、モバイルクライアントがWebページまたはサービスと通信しているかどうかには関係ありません。この決定は（指摘したように）セキュリティや複雑さ、または拡張性（つまり、ボトルネックがサービスまたはWebサイトにあるかどうか）に関係していると思います。しかし、十分に大きく複雑で重要なWebサイトの場合、これらの要因はすべて個別のマシンを使用することに傾いていると思います。
したがって、ボトムアプローチをお勧めします。