Is it a good idea to put class parameters in a session object?

I recently asked a question about storing the results of a database search in whi开发者_Python百科ch I put a datatable with over 100,000 records into a session object and then would retrieve that session on another page and bind it to a gridview and display the results. This is obviously not very good, so instead of doing that, is a good option to store the parameters for the search in a session object and pass that to the results page and run the search query on that page instead.

Much better! Just access the Session object on the other page - no need to "pass" anything.

It's as good an idea as any other. If there are a limited, specific amount of terms you may want to include them as part of the URL and query them using Response.QueryString.

I think this solution is much more lightweight and works in most scenarios. However, on occasion I run into a situation where I want a lot of data to be longer lived than the request but not necessarily have to store it in session or app state.

For example, sometimes the user runs a query and gets back some results for which he/she views some summary info. At that point, he/she only wants to work on those results and not the results of another query run in a few seconds. Sometimes these data are rather volatile and a even a small timespan between queries can mean the difference between 100 records and 108 records, or the difference between these 100 records with some state X and the same 100 records with state Y at some later time.

Enter the OODB/RDBMS Hybridization Model
Although, this has been tackled in several ways, the nicest method I've come up with is to use a hybrid of RDBMS and OODB to eliminate the memory inflation of storing the records in session state. Basically, I put a db4o database file on the web server and read the records from the RDBMS into an object graph and then persist this graph into db4o. After the user is done with the results, I delete the graph from db4o. Leveraging db4o's transparent activation and persistence, it works brilliantly!

Object databases have solved quite a few issues like this for me; and even when my app sits on an RDBMS, a library like db4o allows me to bridge the gaps between memory consumption and "shorter-long-lived" (or "longer-short-lived") data.