How do you retain Variable values after Postback?

[pabowen]

I am revisiting an aspx page I wrote a while back that needs some performance improvements. When I wrote the page it was early in my understanding of c# and asp.net (not that much further along now...)

The problem I had, is that I had to repopulate values every time I posted back to the page. There were alot of controls on the page, so it could repost back several times on a visit. This creates an obvious performance issue, since I had to hit a large dbase with probably 6 different statements for each post back.

How can I avoid this? Is there a way to populate the variables so they retain their value?

Any help would be appreciated, even if it is just a link to a site, or even the name of a topic I could google.

Thanks.
Patrick

 

[B00gyeMan]

One solution would be:

In Page_Load do the following:
1) If it is not a postback, initialize the variables as needed. Then store them in the Session object.
2) If it's a postback, attempt to retrieve them from the Session object (if you cannot find them, re-initialize them as in step 1.)

P.S.: You should create a structure to hold the variables, it's much easier to write a single line like Session[ "PageData"] = m_Variables; than to write a line for each variable you need to store.

 

[B00gyeMan]

I forgot the link:

http://msdn2.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.aspx

 

[jshurst]

Also, with Sessions you need to think about a few things. First of all is the server going to be load balanced? If so then you'll need to store the sessions at the database level.

Also what do you mean you had to repopulate values? You mean values of things like textboxes, and dropdown lists? If that is what you are talking about then you can do the following...

on the page load add

If Not Page.IsPostBack Then
'Load your variables
End If

That way you won't loose the values. If you need to persist values in the code behind then you'll need to use sessions, cookies, viewstates, or hidden variables.

 

[dEVooXiAm]

Apart from all said - 1 thing - DONT use hidden variables

------------------
When you do it, do it right.

 

[pabowen]

I take it that using hidden variables is bad? Could you explain why?

I appreciate it.

Patrick

 

[stevexff]

Basically, you are using non-displayable fields on the form to hold data between interactions. because it gets sent out to the browser, and then sent back again, it can be used to hold state information. I's bad because it uses up network bandwith sending stuff backwards and forwards all the time, and because you are in effect sending the guts of your application out to the browser where it can be inspected and possibly tampered with.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[dEVooXiAm]

Why bad? Simple - what you send to the client - is what the client can change. If you use hidden variables, you better make sure it is not critical data, and better double check what comes back from the client, because that can be anything from silly data to something trying to hack the system. Assuming the dificulties of checking the input (which from program's point of view never should be "input"), the use of hidden variables is not recommended.

------------------
When you do it, do it right.