0

私が働いている場所では、いくつかの Web アプリケーション (WebForm および MVC) を Web ファームに移行しています。セッションは SQL Server によって管理されます。

問題はこれまでレガシーです！

これらのケースでは、セッションの使用、文字列の保存、戻り値などがより簡単になり、コードはそのまま残ります。この問題は、いくつかの特定の状況で、List<typed>シリアライズできないオブジェクトなどがセッションに保存されたときに発生します。

私は、このすべてを DRY スタイルでリファクタリングする方法を考えています。

セッションに保存されているほとんどのリストは、Entity Framework クエリの結果のコレクションです。正直なところ、近道があるかどうかはわかりませんでした。すぐに思いつく唯一の解決策は、レガシーシステムのデータベースにテーブルを作成してそれらのオブジェクトを保存し、非アクティブな行を散発的に削除するメカニズムを作成することです。

したがって、以下を利用する場所ならどこでも：Session["mList"] = myList;

私は以下と交換します：CustomSession.AddsInDatabase("mList", myList);

ログインユーザー、挿入時間などを適切に管理します。

それは良い代替案ですか、それとも他にありますか?

:)

4

1 に答える 1

0

Microsoft によって実装されたSQL Server セッション状態プロバイダーを使用したくない理由はありますか?

はいの場合は、カスタム セッション状態プロバイダーを実装することをお勧めします。カスタム ルートを使用する場合は、常にセッション値をバイナリ BLOB としてデータベースに保存し、BinaryWriterwithSessionStateItemCollection.Serializeを使用して呼び出し間でシリアル化および逆シリアル化することをお勧めします。これにより、オブジェクトのタイプについて想定する必要がなくなります。あなたが保管しています。

このMSDNのカスタム プロバイダの実装例を調べると、 から継承されたクラスの実装にどのような作業が必要かがわかりSessionStateStoreProviderBaseます。

于 2012-08-08T20:00:53.720 に答える