セッション内のページ全体でユーザー (およびユーザーの所属先) に関する情報を記憶する必要がある ASP.NET アプリケーションがあります。
これは、特定のサイズのほぼすべての ASP.NET アプリケーションの要件であると思います。私は何年にもわたっていくつかの異なるアプローチを使用してきました。
過去に、次のようにクエリ文字列パラメーターで id を渡しました。
site.com/page.aspx?usrid=1&companyid=2
次に、各ページで (データベースから) オブジェクトをインスタンス化します。
それを行う別の一般的な方法は、オブジェクトをセッション変数に格納することです。
Session["User"] = currentUser; // store at login
User currentUser = (User)Session["User"]; // retrieve on some other page
DB へのアクセスを節約できますが、User オブジェクトが複雑で、サイトに多くの同時ユーザーがいる場合に使用されるメモリが心配です。
最近、次のように、マスター ページでパブリック プロパティを使用するアプリケーションを継承しました。
Master.theUser = currentUser; // store at login
User currentUser = Master.theUser; // retrieve on some other page
これによりキャストが保存され、読みやすくなると思いますが、パフォーマンスが良いか悪いかはわかりません。また、getter には、プライベート値が null の場合、Session 変数から取得しようとするロジックもありますが、それが使用されていないか (またはgetごとに使用されている!?) かどうかはわかりません。
私の最新のアイデアは、私のページクラスを使用することです。標準の System.Web.UI.Page 基本クラスから派生したカスタム ページ クラスがあります。パブリック プロパティとして CurrentUser などのオブジェクトが含まれます。これはうまくいくようです。私はそれがさらに好きです。
しかし、その裏で何が起こっているのか、私には本当にわかりません。どちらのアプローチが優れているか、またその理由について意見を言える人はいますか?
これを行うための別の提案も歓迎します。
更新: trace.axd と Trace.Write を使用していくつかのチェックを行ったところ、マスターページ バージョンもカスタム ページ クラス バージョンもページ間の値を「記憶」していないようです。「get」メソッドには、User プロパティが null かどうかをチェックするコード行があり、null の場合はセッション変数から読み取ります。これは、特定のページでページがプロパティ (Master.User または派生クラスの this.User) に初めてアクセスしたときに発生し、その後の要求は (セッション変数に移動することなく) 値を取得できます。