In most cases you can count on Serialization being faster than going back to the backend...

However, the right place to dump this stuff more likely is going to be the Cache object for most reusable things. Storing data on a per user level is going to be too fat for most applications - too much data stored memory (with both InProc and StateServer state stores).


+++ Rick --

>>>what I tend to do is create a table w/enough rows for all of the data (denormalized, obviously). As the user fills in each field/set of fields, I store this info into the table. One of the fields in the table is some sort of identifier I can use to tie the session to the user ( usually the session ID: Session.SessionID). This makes it really easy to handle a lot of common information between pages.
>>
>>
>>Just to clarify, Paul, are you then saving that DataTable as a Session variable?
>
>I suppose you could. My initial reaction wouldn't be to do that. That's probably my VFP background talking, though.
>
>I have no idea what the performance differences are; is it faster to serialize/deserialize an object or just requery it when it's needed? I guess, maybe so, ignoring the memory requirements. But the other aspect of this is how/where are you storing your sessions (eg. default "in memory", or SQL server)? If the session is being dumped to SQL server so you can maintain state across load-balanced servers (and to be able to cycle a server and not lose a session), is it going to be better to grab the info. from SQL server as needed, or have it grabbed when the session is restored on the next hit?
>
>I think in most cases I'd still prefer to grab the data directly from the backend as-needed instead of persisting it to the session. I just don't have a good argument as to "why" I'd lean that way, although I guess I could come up with some unproven statements about sessions and mumble something about memory usage <g>