2

I have recently started researching how to use a custom view-state provider to move storage of viewstate from the page to the server. The obvious advantage of this is reducing the rendered page size and thus, increasing the user experience. Also, the biggest disadvantage that I know of is that server memory usage will increase. For this issue I can easily move the storage to a different server than the web server (AppFabric, for example) Besides this, are there other pitfalls that may arise? Are there situations where one would use the normal view state provider and not a custom view state provider?

I hope my question is clear.

Thanks!

Muhammad Akhtar
  • 51,913
  • 37
  • 138
  • 191
O.O
  • 11,077
  • 18
  • 94
  • 182

2 Answers2

2

Recently I did this in my application and have not had any issue doing so.

But before moving to maintain a custom Viewstate, you have to think of User traffic. If traffic is high then I would not recommend maintaining Viewstate on the server. In that case you have to consider other ways to improve the performance of your application.

Have a look on this very good article an Analysis of Keeping ViewState out of the Page

Off The Gold
  • 1,228
  • 15
  • 28
Muhammad Akhtar
  • 51,913
  • 37
  • 138
  • 191
  • Even if it was not stored on the same server as the application? – O.O Apr 14 '11 at 18:03
  • yes, it will not be a problem. then main thing is how you implement this. have a look article in details. then later on I will show you the technique how we are doing. – Muhammad Akhtar Apr 14 '11 at 18:05
  • Ya, caching would be a better approach than storing it in a singleton dictonary (easier to scale) – O.O Apr 14 '11 at 18:34
1

If the thread/process that holds that data crashes you'll lose it (given you're going to store it in memory). Same thing with inproc/aspstateserver session. Sometimes it just crashes = goodbye, data. But it's impossible when your viewstate is stored on page = more reliability.

Dmitry
  • 3,069
  • 1
  • 17
  • 26