1

ホスティング会社を使用せざるを得ないため、(Web) プレゼンテーション ロジックとビジネス ロジックをファイアウォールで分離された 2 つの異なるサーバー/層に分離する必要があります。プレゼンテーション ロジックを備えたサーバーのみがインターネットに公開されます。正当化はセキュリティです。DB を備えた 3 番目のサーバー/層がありますが、それは些細なことです。このシナリオで役立つアーキテクチャ モデル/デザイン パターンを探しています。

3 層 Web アーキテクチャに関する Microsoft の説明を見つけました: Improving Web Application Security: Threats and Countermeasures。Microsoft 独自のホスティングでは、 Windows Azure セキュリティ ガイダンスという 2 層アーキテクチャが使用 されています。

例えば。MVC パターンを使用すると、コントローラーとビューをプレゼンテーション ロジック サーバーに配置し、モデルをビジネス ロジック サーバーに配置できます。次に、通信のために各サーバーにサービスレイヤーを配置できますが、サーバー間でセッション、ユーザー認証などを共有する必要があります。

それを行う賢い方法は何ですか？どなたか記事などへのリンクを教えていただけないでしょうか。

4

1 に答える 1

1

セッション状態は、ドメイン状態と直交する必要があります。セッション状態をビューレイヤーに保持し、サービス/ドメインレイヤーを可能な限りステートレスに保ちたいと思うでしょう。これは、ユーザー情報をコントローラーからサービス層に渡す必要があることを意味します。

これが問題になり、長時間のセッション状態が必要な場合は、それを別のストアに外部化し、渡されたセッション情報にリンクします。これにより、ドメイン層の「セッション」がビュー層の「セッション」から分離されます。したがって、モデルとビューの間の抽象化を維持します。

ビュー/コントローラー レイヤーにビジネス ロジックのブリードが発生し始めるでしょう。それを認識し、それを制御するように努めてください。

MVVMパターンは、MVC よりもはるかにこれに適合する可能性があり、ビジネス サーバー側でビュー ステートをより適切にカプセル化します。ただし、セッションはまだ問題になっています。ビュー/ビジネスレイヤーで個別のセッションが必要/必要になりますが、ビューレイヤーのセッションは非常に軽量になります。基本的には、認証を処理し、ビューモデルがリンクできるようにサービス層に渡すことができるキー (sessionid) を持つ必要があるだけです。

于 2013-10-04T12:46:03.677 に答える