1

静的メンバーがASP.NETWebサイトのすべてのユーザーによって共有されることを理解しています。しかし、この特定のケースでは、まさにそれが私が望んでいることです。

これは、2人のユーザー間のWebベースのチャットを容易にするために私が一緒に作成した私用のWebページです。データベースまたはデータファイルにデータを永続化することを避けたかったので、最後のXメッセージを静的並行キューに格納できると思いました。これは私の開発マシンではうまく機能しているようです。

私はASP.NETに非常に不慣れですが、私が見つけたすべての例で、このアプローチを使用しているものはありません。これは悪い習慣ですか、私が知っておくべき「落とし穴」はありますか？私が見ることができる代替案は、データベースを使用することです。しかし、私はそれがより多くの努力であり、私の推測では、より多くのリソースであると感じました（メッセージの「バッファ」は約40kbのメモリを必要とし、データベースへのかなりの数のトリップを節約すると思います）。

4

4 に答える 4

8

全体がスレッドセーフであることを確認すると、それは機能します。

ただし、IISはいつでもAppDomainをリサイクルできるため、予期しないときにキューが吹き飛ばされる可能性があります。

于 2012-06-05T16:10:24.440 に答える
3

IISがAppDomainをフラッシュして再起動しない場合でも、この目的で静的変数を使用することは、私には悪臭を放つハックのように思えます。

このHttpApplicationStateクラスは、情報の保存に使用できるアプリケーション全体のキャッシュへのアクセスを提供します。

ASP.NETアプリケーションの状態の概要

于 2012-06-05T16:13:34.710 に答える
1

確かに、私が過去に見た1つの落とし穴は、で静的変数を使用することでしたWeb Gardens。

このSOの質問を参照してください： Webガーデンと静的オブジェクトを理解するのは難しい

議論の要点に注意してください。

静的オブジェクトは、Webガーデン/Webファームでは共有されません。

于 2012-06-05T16:17:34.230 に答える
1

要件が変更されず、サーバー側のすべてのメッセージをランダムに失うことに問題がない限り、これはまったく問題ありません。

コードを少しリファクタリングして「メッセージストレージ」インターフェイスを提供し、コードのテストを簡素化します（将来、コードをより複雑/永続的/マルチユーザーにすることにした場合は、潜在的なメリットがあります）。

静的ストレージアプローチ（またはHttpApplicationState）の長所：

  • メッセージのサーバー側ストレージに問題はありません-プライバシーの懸念が少なくなります。永遠に保存されるものはないので、好きなことを言うことができます。
  • 非常にシンプルな実装。
  • IM/電話での会話に最適です。
  • 単一サーバーの場合にパフォーマンスの問題が発生する可能性は低い

短所：

  • メッセージが失われる可能性があります。クライアントに履歴を保存することで軽減できます（つまり、同じWebページでAJAXクエリを使用してメッセージを取得します）
  • より多くのユーザーが関与している場合、または静的データがすべての人に表示されるため、アプリケーションが他のコードと共有されている場合にデータが機密である場合は、さらに注意が必要です。また、他のストレージと大差ありません。
  • 複数のサーバー/Webガーデンシナリオに直接移行することはできません。2人のチャットサーバーで問題が発生する可能性はほとんどありません。
于 2012-06-05T16:36:07.877 に答える