私はこのトピックを読みましたが、まだ全体像を把握できていません。次の質問への回答をいただければ幸いです。
SOA は、JSON を Web クライアントに送信するだけではありません。
販売、在庫、レポートなどのデータベース駆動型ソフトウェア システムを使用するビジネスを考えてみてください。ほとんどのシステムは、クライアントまたは Web アプリがデータベースと直接通信するだけの小さなものから始まりますが、それで問題ありません。
ただし、システムが成長するにつれて、このモデルにうまく当てはまらないことがいくつかあることがわかります。アプリまたは Web ページをロックする長時間実行されるバッチ プロセス、データベース サーバー以外のものが関与するスケジュールされたジョブ、外部ソースに存在するデータを含むプロセス、または実行中に DB を停止させる複雑なレポート。
この時点で、アプリケーション サーバーを追加して、これらのタスクの一部を処理することを検討する必要があります。アプリケーション サーバーは、そのワークロードの一部をクライアントから取り除くことができます。また、アプリケーション サーバーが生データを要求したり、DB との間で生データを要求したり、DB からデータを移動したり、ユーザー向けクライアントが変換されたデータを要求/送信したりするなど、過負荷のデータベースになる可能性がある特定の負荷を軽減することもできます。アプリケーションサーバーから。
システムがさらに成長するにつれて、物事を維持していると、システムのさまざまな部分が別の場所に予期しない副作用をもたらすことにも気付くでしょう。単純な拡張機能でさえ、完了するのがますます複雑になっています。開発は遅くなり、バグ数は増加します。アプリケーションサーバーは、ある領域での変更が他の場所で期待される結果 (および期待される結果のみ)を確実にもたらすようにするための設計作業を集中化するのに最適な場所になりました。
最初に、SOA が実際に何であるかは、そのアプリケーション サーバー (たまたま http 経由で json を使用する可能性がありますが、まったく異なるインターフェイスを提供したり、複数のデータ転送テクノロジ間で自動的に変換することさえある可能性があります) を使用し、すべてを強制することです。データベースへのアクセスは、このアプリケーション サーバー (サービス層) を経由します。
このアクセスが強制され、データベースと直接対話するものがなくなると (少なくとも、特に説明されていないものは何もありません)、レイヤーはビジネス ルールとシステム ロジックの強制を開始するのに最適な場所にもなります。SQL よりもソース管理で使いやすく、システムを使用するすべてのアプリケーション間で自動的に共有される、従来のアプリケーション スタイルのコードをここに記述できます。コードはすべてほぼ同じ場所に存在するため、システムを通じて変更とその影響をモデル化することが容易になります。
おまけとして、このレイヤーは、特に従来のリレーショナル データベース サーバーと比較して、複数の冗長サーバーにスケールアウトするのが非常に簡単です。その結果、アプリケーション サーバーをスケーリングすることで、大規模なアプリケーションのパフォーマンスと信頼性を改善および管理することができます。バックエンドでは、Redis などのデータベース キャッシング ツールを使用する作業を簡素化および集中化することでパフォーマンスを向上させ、パフォーマンス チューニングに専任の DBA を関与させやすくし、複数の場所に存在するデータへのアクセスを集中化するのに役立ちます。
この時点で、MVC Web サイトは、SOA システム内のアプリケーション サーバーに接続するもう 1 つのアプリにすぎません。また、一部のデスクトップにレガシー クライアント サーバー アプリがインストールされている場合や、MVC アプリが公開販売されている一方で、実際の営業担当者とサポート担当者はまったく別のものを使用し、請求には別のアプリを使用し、注文のフルフィルメントまたは調達にはさらに別のインターフェイスを使用している場合があります。 ...しかし、それらはすべて同じサービス層と通信します。ここでの追加の利点は、このサービス層が複数のソースからデータを簡単に取り込むことができることです。したがって、製造システムが外部システムからの材料の入手可能性情報を必要とする場合、サービス層はそれを見つける方法を知ることができ、フロントエンド コードは知りません。このデータが特別な場所から来たことを知る必要はありません。
このすべてのポイントは、どちらか/またはここの場合ではないということです。SOA を使用している場合は、システムの 1 つのレベルで MVC を使用できます。SOA のサービス レイヤーによって提供されるインターフェイスによって、MVC モデルがどのように見えるか、およびコントローラーがどのように動作するかが決まります。SOA がない場合、MVC はたまたまデータベースからプレゼンテーションまでのスタック全体の構築に問題なく機能し、実際にはモデルがより大きなサービス層の縮図になるように機能します。
したがって、いつ JSON を使用するか、いつ ASP.Net MVC を使用するかという問題は、新しい形式をとります。ASP.Net MVC は SOA アーキテクチャの一部にすることができ、多くの場合、JSON データを提供するサービス フレームワークはクライアント側の MVC ライブラリを使用して実装されます。クライアント側でより多くのことを行うのと、サーバー側でより多くのことを行う方が適切な場合を本当に知りたいのです。正直なところ、これは主に個人的な好みだと思いますが、注意すべきトレードオフがあります。
クライアント側でより多くの作業を行うと、アプリケーションの作業負荷の一部がユーザーのコンピューター システムに分散され、Web サーバーまたはアプリケーション サーバーへのラウンド トリップによって発生する待ち時間が短縮されるため、パフォーマンスとスケーラビリティが向上する可能性があります。
一方、サーバー側でより多くの作業を行うことは、低速のパブリック インターネット リンクを介してより大きなデータ セットを転送する際の遅延を回避するのに役立ちます。また、JavaScript が多すぎると、アクセス可能なブラウザーやクライアント システムへのデータのプッシュに関する問題は、プライバシーまたはセキュリティのリスクを構成する可能性があり、より多くの処理がすべて同じレイヤー内で行われると、新しいコードの開発、展開、および保守が容易になる可能性があります。
クライアント側のMV*（MVC、MVP、MVVMなど）アーキテクチャとサーバー側のMV *アーキテクチャは、アーキテクチャのSOA部分に関する限り同じです。
モデルは、サービスと通信し、さまざまなサービスからデータをフェッチする場所です。クライアント側のMV*とサーバー側の選択は直交しています。