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