Persist c# objects across postbacks

c# asp.net postback partial-postback

10,613

Solution 1

Put the objects into the Session for the current user.

Solution 2

Put all your initialization stuff in an (!IsPostback) { } and use partial postbacks. That way the initialization code doesn't get called again during the postbacks.

Solution 3

Why don't you cache the object?

Caching API, Using the Cache Object: http://msdn.microsoft.com/en-us/library/aa478965.aspx#aspnet-cachingtechniquesbestpract_topic4

10,613

Author by

uscere90

Updated on June 24, 2022

Comments

uscere90 almost 2 years

I've got an asp.net page that has c# code-behind that does some stuff in the Page_Load() method (like query a database and make a few other calls to populate objects with data). I then display this data on the page. This all works fine. I set up a couple of postbacks so that when a value in a listbox is clicked, a panel control is filled with the rest of the corresponding object's data. I thought postbacks were the right way to do this, but this causes the (entire class?) to be re-called, which re-initializes my objects and destroys the data I want to keep.

Will some form of partial-postback solve this problem, or is there a better way to implement what I'm trying to do?

I don't want to re-populate the objects every time a postback is called, as that takes a database query, and I want to avoid re-querying every time something is clicked...

I've found many questions regarding persisting Javascript objects, but nothing that really seems to address this. I'm using .Net 4.0
uscere90 almost 13 years

Ok, is still doing a full postback considered the proper way to do this? Or should I be making use of some kind of ajax or partial-postback to only change certain parts of the page?
Yuck almost 13 years

You're onto a different subject entirely now. Keeping variables and objects for a user between postbacks is best handled by Session - either InProc in using a SQL Server database. Whether or not you want to do a full postback or use AJAX is dependent upon how your application is laid out. Refreshing a grid or list, for example, is probably best handled using an AJAX refresh as you only need to grab the data and not page layout elements, etc. Hope that helps.
Chris almost 13 years

I would not recommend putting objects in session.
uscere90 almost 13 years

@Chris Can you elaborate? That comment isn't helpful at all. I can't just take your word for it, I need to know why you don't recommend it.
Chris almost 13 years

Sorry ;) Putting whole objects into session is not recommended since, depending on the session state you choose (and you never know which one you are using in future), your object might need to be serializable. Another thing is: Storing things in session should only be done for "global" purposes (like a specific selection in your intranet is made that you need to carry around the sessions lifetime). What happens if the user opens another window and opens the same page within the same session? You have to take care about that then...
Yuck almost 13 years

The problem you described is application-specific and without knowing the details I stand by my recommendation. For many LOB applications I've worked on I don't really care how many tabs or windows (in the same browser process) a user opens - it's the same session.
uscere90 almost 13 years

I've got that in the Page_Load section - the problem I'm running into is variable scope. I've a number of methods I use to work with these objects, so they're declared as class-scope variables. When I do a full postback, they get re-declared and the old ones are destroyed.
Marcus almost 13 years

You could use ViewState instead of Session to hold the variables. That way they only live within that page.