State Management

[Guest]

Can collection classes be used to store session data? In a couple of books on
ASP.Net where they discuss state management (to capture a user's input data),
they talk about session and application objects, cookies, statebag, etc.

But if I have a checkboxlist, can't I just iterate through the selected
items and store them in a collection class for use in later pages in the web
app? Would there be implications of doing it this way?

Thank you,
Richard

 

[John M Deal]

The only issue to be aware of (in your collection scenario) is
serialization. If the collection that you put the objects is not
serializable you'll get an exception if someone decides to activate SQL
or Out-Of-Process session state as these session storage methods
serialize the object across process boundaries when storing and
retrieving the data. Of course this assumes that you use session to
temporarily store state.

You mentioned other ways of storing the user data each has its own
issues. You don't want to use the application level storage for
handling the storage of user specific data as you're giving every user
potential access to every other user's data, not to mention that the
data will stick around in memory until the application ends or you take
pains to shut it down. If you are looking at cookies you'll need to
make a call on how much data you want to store and transmit across the
line between the user and the server.

We've found that on the whole using serializable data containers to
store data in Session seems to be the most flexible and manageable
solution to temporary storage of state. We usually abstract the calls
to state storage in a wrapper class so that we can change the storage
methodology as our needs dictate (i.e. custom storage repository,
security requirements...).

Have A Better One!

John M Deal, MCP
Necessity Software

 

[Guest]

John, thank you for this info!

The only issue to be aware of (in your collection scenario) is
serialization. If the collection that you put the objects is not
serializable you'll get an exception if someone decides to activate SQL
or Out-Of-Process session state as these session storage methods
serialize the object across process boundaries when storing and
retrieving the data. Of course this assumes that you use session to
temporarily store state.

You mentioned other ways of storing the user data each has its own
issues. You don't want to use the application level storage for
handling the storage of user specific data as you're giving every user
potential access to every other user's data, not to mention that the
data will stick around in memory until the application ends or you take
pains to shut it down. If you are looking at cookies you'll need to
make a call on how much data you want to store and transmit across the
line between the user and the server.

We've found that on the whole using serializable data containers to
store data in Session seems to be the most flexible and manageable
solution to temporary storage of state. We usually abstract the calls
to state storage in a wrapper class so that we can change the storage
methodology as our needs dictate (i.e. custom storage repository,
security requirements...).

Have A Better One!

John M Deal, MCP
Necessity Software