Using Session state is not a huge thing as long as they're simple. Even complex ones are not a huge deal so I wouldn't worry about this too much at least from a performance issue. Storing things in other places is actually more expensive usually. the main issue with Session overload is that you have these variables scattered all over the place.

However from a design perspective it might be confusing to have too many separate session vars. If that's the case you can create an application related session object that is serializable and add properties to it for the variables that you want to store. Just a simple object with properties on it - mark it as [Serializable()] or inherit from MarshalByRefObject and then add proeprties.

The advantage is that you get fully typed access to these properties and you have a class that has a clearly defined interface that can be documented. You can even use sub objects to delineate sub-options properly. Furthermore you can just read and write to the Session object once (at startup and end of the form) even though this hit is somewhat more expensive as it has to serialize this object. But since you're only reading and writing the session once it should still be fairly quick.

+++ Rick ---



>Hi All,
>
>How do I pass parameters between web forms? Is this even allowable in a web app?
>
>We are using way too many session variables. What is a best practice for this?
>
>Thanks,
>
>Jacci