8

すべてのリクエストでデータベースからデータを取得しないように、ポストバック全体でオブジェクトの永続性を処理する方法を決定しようとしています。私はSession（イントラネットアプリケーションであり、数千人のユーザーは存在しません）を使用することに傾倒していますが、これは、実際のオブジェクトへの参照のみがそこに格納されていると思われるためです...

これが本当かどうか誰かが事実を知っていますか？

私はいつもセッションオブジェクトを使いすぎないように教えられてきましたが、このように機能すれば、それほど大きな問題にはなりません...

ここで実際にセッションに保存されるもの：

Session["myKey"] = myObject;

実際のシリアル化されたオブジェクト、またはその参照？

4

6 に答える 6

7

私はこれを試しました：

クラスを作成し、このインスタンスをセッションに保存しました (セッション状態モード: InProc)。インスタンスは aspnet_wp.exe proc に存在します。

次に、セッション状態を SQL Server (まだ [Serializable] 属性なし) に変更すると、次のエラーが発生しました。

セッション状態をシリアル化できません。'StateServer' および 'SQLServer' モードでは、ASP.NET はセッション状態オブジェクトをシリアル化するため、シリアル化できないオブジェクトまたは MarshalByRef オブジェクトは許可されません。

そのため、inProc セッション状態のシリアル化はありません。

乾杯... マーティン

于 2008-12-02T20:05:20.510 に答える
4

ASP.NETは、ユーザーを識別するためにデフォルトでCookieに格納されるGUIDを作成します（ただし、クエリ文字列の使用を指定できます）。そのCookieに関連付けられているオブジェクトは、デフォルトでIISプロセス内のサーバーに保存されます。

たとえば、セッションオブジェクトをアウトプロセスのままにしておきたい場合は、カスタムセッションオブジェクトストア（Session-State Store Providers）を作成することもできます。

詳細はこちら：

http://msdn.microsoft.com/en-us/library/ms178587.aspx

しかし、実際にあなたの質問に答えるために...

箱から出して、セッションストアがオブジェクトへの参照のみを格納するという仮定で正しいです。

ただし、シリアル化を実現するために、web.configでセッション機能のストレージ動作を指定することもできます。3つのモード：

  • InProc-Webサーバー（aspnet_wp.exe）でライブオブジェクトとして保持されるセッション。web.configの「cookieless」構成を使用してsessionIdをURLに「変更」します（cookie / domain / path RFCの問題も解決します！）
  • StateServer-別のプロセス（aspnet_state.exe）でシリアル化され、メモリに保存されたセッション。StateServerは別のマシンで実行できます
  • SQLServer-シリアル化されてSQLサーバーに保存されたセッション

上記は、http ：//www.eggheadcafe.com/articles/20021016.aspからのものです。

于 2008-12-02T19:39:31.280 に答える
4

使用するセッションによって異なります。inprocセッションを使用している場合は、セッションで参照を取得しましたが、それ自体を参照している間は、オブジェクトへのリンクにすぎないため、オブジェクト全体がプロセスメモリ内に保持されます。ユーザーあたりのデータ量と1時間あたりのアクティブユーザー数を知ることは非常に望ましいことです。プロセスメモリ内のオブジェクトは、procセッションで使用する場合はシリアル化されませんが、procセッション外で使用する場合はシリアル化されるため、パフォーマンスに影響を与える可能性があります。

ここで、セッションとキャッシュの非常に優れた概要を見つけることができると思います

于 2008-12-02T19:42:38.840 に答える
2

セッション変数に複雑なオブジェクトを格納する (技術的には、前述のオブジェクトへの参照を格納する) ことを嘆く記事やブログ投稿がたくさんあります。一般的に、私はセッション変数は悪魔の仕業だと考えており、それらを回避するためにできる限りのことをしています。

とはいえ、Juan Manuel が説明するように、開発者がセッション セッションの過剰使用によるスケーラビリティへの影響を完全に理解しているイントラネット展開アプリの場合、私はそれを何度も行い、大きな成功を収めてきました。はい、セッションはリサイクルできますが、これは異常なエッジ ケースです。合理的なセッション タイムアウトでブラウザ アプリに影響を与えるほど定期的に発生するわけではありません。

少なくとも最初は、Juan Manuel さんが提案する方法でアプリをビルドすると思います。ただし、セッションからオブジェクトを保存して取得する場所を離れて（おそらくラッパークラスを使用して）、アプリケーションが要求した場合に後で簡単に変更できるようにします。

于 2008-12-02T20:08:43.200 に答える
0

In-Proc セッション データは非常に脆弱であることを覚えておくことが重要です。つまり、最も必要なときにそこにない可能性があります。なんらかの理由でワーカー プロセスがリサイクルされると、それはなくなってしまいます。

于 2008-12-02T19:51:51.520 に答える
0

現在、パフォーマンスに関する懸念はあまりなく、セッションはおそらく問題なく動作することを理解しています。ただし、状態を維持したり、ポストバック間でデータを運ぶ方法は他にもあります。

同じページのポストバック間でデータを保持しようとしている場合は、代わりに ViewState を使用することをお勧めします。ViewState に格納されたデータはシリアル化され、保持するオブジェクトは ISerializable を実装する必要があることに注意してください。

于 2008-12-02T19:56:19.153 に答える