How to persist data across the application's session......

Dear All,

I have a need to persist session data across different pages. A good example of this is the current User profile. With my pre .net apps I used a session variable to store an identifier, and the session data I persist in an XML structure which can be stored in memory or on file (accessed via the session variable identifier). This method is very useful for its transparency and structure, and for the fact that I use XSLT quite a bit, so I can transform directly from this XML.

However I am now researching the ASP.NET methods, and Viewstate looks useful, but I am unsure whether it can be used across an application's session.

Thoughts please.....what is the best approach in the ASP.NET world?

Thanks,

Sam
SamJollyAsked:
Who is Participating?
 
b1xml2Commented:
ViewState is generally invariably used by the developer for persisting data across postbacks. It is not a good idea to persist it in Session both for performance as well as scoping issues.

1. If a user opens a new window via Control+N or a new tab in FireFox, he may be re-using the same session. What if the user views the same page in 2 different windows/tabs. The result will be unpredictable.

2. If the user wants to store it in the Cache, the user must remember that the Cache can clear items out to manager resources. So in the event of high resource usage (peak hour), the Cache may flush the item and the behaviour may be unpredictable. On the other hand, if one does one's resource well enough, and measures the web performance, it may well be acceptable subject to the fact that the Cache object can release its items at any time of its choosing, overriding the expiry policies of the cached item properties.

3. The View State has the unenviable task of persisting data across postbacks where the data is stored on the client-side and is reconstructed server-side. This point is sometimes lost on some of us. What this means is that unlike the Session object, the ViewState object never loses its data even though the Cache and Session objects may have already expired. The View State can bloat up the client pages. Dino Esposito has shown how to move the ViewState to the server instead of residing on the client. This takes off from the total page size quite a large amount of gibberish. ASP.NET 2.0 has better and more streamlined ViewState processes.

4. Data in ViewState is not safe. Thus you are encouraged to set the ViewStateMac to true to enable authentication of the validity of the data posted back.

5. I always as a rule use ViewState to persist data across postbacks for data not considered senstive (both intranet/internet)

6. I store the ViewState server-side when I need to use ViewState and the data is sensitive.

7. Session is always good for data that is global in nature and not specific to data in pages. Do not use Session to store metadata of pages based on some parameter for the page. This leads to unimaginable consequences when two windows share the same data.


0
 
RejojohnyCommented:
Viewstate in not used to persist data between different pages .. it can used between multiple postbacks of the same page .. for ur requirement, u can continue using the session varible as u have been using in ur old ASP days ...
0
 
SamJollyAuthor Commented:
Thanks for your comment.

This viewstate mechanism is a double edged sword, because you may not want to dump all your persistent data over the network each time a page is rendered. I would have thought that it was more efficient to store it locally on the server..???

With my XML structure I has a section for form data, querystring, derived valaues and resultsets from a database.

I am just reading up on the improved Session mechanism with cookieless ID and State services for web farms etc. which all seems positive. So why bother with another mechanism just for page rendering ie ViewState or am I missing something.

Sam
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

 
RejojohnyCommented:
viewstate is not normally user by the developer to maintain the state .. it is used by ASP.net to manage the state of the page .. for eg. in old ASP daya, if u had a dropdown, u will have to add the list of items into the dropdown evertime the page is posted back to the server and shown to the user (multiple postbacks). Even the last selected item would have to be re-populated so that the user the last selected value defaulted in the dropdown .. all this is handled automatically by .net. using Viewstate ... u could also use viewstate to presist data between multiple postbacks of the same page .. but this would not be available the moment you redirect to another page .. so, as i mentioned for persisting data like the user profile which is very specific to the currently logged on user and session .. use the session variable .. if u have a data which is at the application level, instead of using the application object (as in the ASP days) have a look at application cache wchihch is somewhat similar to the application object but with some more useful properties and methods ....
0
 
SamJollyAuthor Commented:
Really interesting feedback. Thanks.

..and the point about ASP.NET 2 making ViewState serverside......so my thoughts on 'dumping' state data over a network are not far off the mark....!! However ViewState is still page centric...??? with  a lot of structure and contents from page controls etc. So the question that begs asking is whether it would be a good idea to extend Viewstate serverside for a session. I suppose this is what I do with my XML session structure.

So until ASP.NET2 comes a long then the best route is ViewState for page persistence, and for session data, a home cooked session variable persisted structure (XML etc) that can make use of the new ASP.NET session mechanism such as Session State services etc...??

Sam
0
 
b1xml2Commented:
ah, umm
ViewState in ASP.NET 1.x as well as ASP.NET 2.0 is still client-side. You can customise your base page to store the ViewState in files on the Server in ASP.NET 1.x as well 2.0. The ViewState in ASP.NET 2.0 is slimmer and less bloated bu it still resides on the client.
0
 
SamJollyAuthor Commented:
Again Thanks....

My gut feel on all of this is that

a) Use ViewState in the simplest way for page persistence, to minimise bloat, and set ViewStateMac to true to enhance security.

b) Use the Session State mechanisms for session data persistence which could be an XML document I guess.

Sam....
0
 
b1xml2Commented:
do not forget to include the cache object.

Use that to store reference data which can be flushed out regularly. It is a very good candidate for this.
0
 
SamJollyAuthor Commented:
Thanks all. Very useful and appreciated.

Sam
0
 
RejojohnyCommented:
as i mentioned above .. have a look at the cache object too .... maybe it fits some other scenario of urs ...
0
 
brdrokCommented:
not sure whether i read your question correctly...but if you like to pass information from one page to another...another possible way of accomplishing is as follows:

in your "source page", you have a dataset you'd like to pass to the next...

public class WebForm1 : System.Web.UI.Page

public DataSet CustomerDataSet
{
      get
      {
            return dsCustomer; //<--this assumes that you have a dataset and filled it with some data
      }
}

and then in your "destination page" page_load event webform 2:

//create a dataset
DataSet dsCustomer;
//create a reference variable to your "source" page
WebForm1 sourcePage;
//add a reference to your source page variable
sourcePage = (WebForm1)Context.Handler;
//get the dataset from the sourcepage to the destination page.
dsCustomer = sourcePage.CustomerDataSet;

0
 
SamJollyAuthor Commented:
Thanks for the further comments and brdrok for an interesting new option. If I could award extra points I would, but I cannot....

So take 500 thank yous instead....  :)

Cheers,

Sam
0
 
brdrokCommented:
no...that's cool.  glad to know you got one more thing to chew on when working with your app =)

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.