Options For "Storing" Data

Session? ViewState? File?

Page 1 of 1

2 Replies - 1154 Views - Last Post: 21 December 2009 - 02:04 PM Rate Topic: -----

#1 eclipsed4utoo  Icon User is offline

  • Not Your Ordinary Programmer
  • member icon

Reputation: 1524
  • View blog
  • Posts: 5,957
  • Joined: 21-March 08

Options For "Storing" Data

Posted 21 December 2009 - 12:05 PM

I am looking for options for storing mission-critical data(payroll data) between postbacks. Normally, I would just use the Session. However, it is possible for a user to sit on this one page for 4-5 hours, and then click a button. On that button click, I will need that data.

1. I could use the Session, but I would need to change the IIS settings to allow for a longer session timeout.
2. I could serialize my custom class and store it in the ViewState. However, I know that's viewable to the user, albeit encrypted.
3. I could write the serialized data to a cookie.
4. I could write the serialized data to a file on the server.

I was moving more toward the ViewState because the data only needs to be stored on the current page. Once the user moves to a new page, I don't care about the data anymore. However, the fact that it is shown to the user makes me kind of "iffy" about using that method.

This site will be an internal site for the customer.

Can anybody tell me which method would be considered the best? By best I mean consistent and secure.

Is This A Good Question/Topic? 0
  • +

Replies To: Options For "Storing" Data

#2 PsychoCoder  Icon User is offline

  • Google.Sucks.Init(true);
  • member icon

Reputation: 1637
  • View blog
  • Posts: 19,853
  • Joined: 26-July 07

Re: Options For "Storing" Data

Posted 21 December 2009 - 02:00 PM

I would say either ViewState or storing it in the Cache. I personally think ViewState causes more of a performance hit than Cache (at least in my experience).

If you decide to go the ViewState route take a look at this snippet of compressing & decompressing ViewState to prevent the bloating that can happen when you store a lot of information in the ViewState. And here's a nice tutorial on ASP.NET ViewState that may help you make your decision, particularly this

Quote

The Cost of View State

Nothing comes for free, and view state is no exception. The ASP.NET view state imposes two performance hits whenever an ASP.NET Web page is requested:

1. On all page visits, during the save view state stage the Page class gathers the collective view state for all of the controls in its control hierarchy and serializes the state to a base-64 encoded string. (This is the string that is emitted in the hidden __VIEWSTATE form filed.) Similarly, on postbacks, the load view state stage needs to deserialize the persisted view state data, and update the pertinent controls in the control hierarchy.
2. The __VIEWSTATE hidden form field adds extra size to the Web page that the client must download. For some view state-heavy pages, this can be tens of kilobytes of data, which can require several extra seconds (or minutes!) for modem users to download. Also, when posting back, the __VIEWSTATE form field must be sent back to the Web server in the HTTP POST headers, thereby increasing the postback request time.

Was This Post Helpful? 0
  • +
  • -

#3 eclipsed4utoo  Icon User is offline

  • Not Your Ordinary Programmer
  • member icon

Reputation: 1524
  • View blog
  • Posts: 5,957
  • Joined: 21-March 08

Re: Options For "Storing" Data

Posted 21 December 2009 - 02:04 PM

Thanks. I will take a look at the cache. I hadn't thought about that.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1