これが私の問題です。管理者全体で複数の画面で使用される大きな患者オブジェクトがあります。各画面には、同じ患者に関するさまざまな情報が含まれています。すべてを1つの画面に表示することはできません。
患者を持続させたいのは、ユーザーが[保存]をクリックしたときだけです。どこかに記憶に残る患者が必要です。ユーザーは管理者であり、さまざまな画面で患者情報を変更し、検証を実行して、その患者を保存しないことを決定する場合があります。これは一般的な使用法です。
この患者をセッションに保存しても大丈夫ですか？または、これを行うためのより良いアプローチはありますか？この管理者には、最大で20人のユーザーがアクセスできます。
これについては意見が異なる場合があります。特にメモリ内セッション以外のものを使用する場合、セッションは注意が必要です。分散セッションは、シリアル化できないオブジェクトを破壊します。このオブジェクトが単純なPOCOまたは制御するオブジェクトである場合は、シリアル化で機能するように最善を尽くしてください。もしそうなら、あなたは設定されています。負荷の少ない管理ツールの場合は、問題ないと思います。
ねえ、私はこれを見つけました-サイトについては何も知りませんが、私のポイントを示しています： https ://www.fortify.com/vulncat/en/vulncat/dotnet/asp_dotnet_bad_practices_non_serializable_object_stored_in_session.html
私は同じような数のユーザーと同じような状況にありました。私はそれをしました、そしてそれはうまくいきました。
私の状況は、イベントのスケジュールに関するものでした。
誰かがイベントを作成し、複数のWebページを介してこのイベントを変更および構成します。それらがすべて完了すると、すべての詳細がSQLに保存されます。結局、私はそれがどれほどうまく機能しているかに驚いた。
セッションはここで問題ないはずです。ユーザーの負荷が軽いように見えますが、オブジェクトが占有するメモリの量を正確に確認し、それをユーザーの最大数で掛けて、現在の状況を確認したい場合があります。
セッションを完全に回避したい場合は、代わりに System.Web.Caching を使用してオブジェクトを保存し、ユーザー識別子と定数文字列を使用して、保存されたオブジェクトにキーを設定できます。
いずれの場合も、アプリケーションを実行している Web サーバーの数を把握しておく必要があります。Web サーバーが 1 つだけの場合でも、心配する必要はありません。複数の Web サーバーがある場合は、それらが「スティッキー」であることを確認する必要があります。これにより、ユーザーはすべての要求が同じサーバーによって処理されることが保証されます。これがどのように行われるかは、負荷分散のフレーバーに完全に依存します... 通常、「IT 担当者」がこれを処理します。