ControlState Thoughts

[JurkMonkey]

I'm currently using ControlState to pass simple objects between postbacks. Can anyone comment on this approach and some things I might want to consider?

I don't want to get half way through development and realize that our architecture was a giant flop.

Thanks

http://www.ubuntu.com/

 

[alan6895]

Hi JurkMonkey.
Depending on what you're passing, you could consider using Session variables. I'm honestly not sure if that's the best way or a better way, but that's what I use when I need to handle cross-page or cross-postback data. Hope this helps!

 

[ca8msm]

Some of the options you have are:

1) ViewState
2) Context
3) Session
4) Cache
5) Application

As you are just saving data for the same page, ViewState is probably the better option as it will reduce the load on the server. You just need to make sure that the page load times are acceptable though as ViewState will increase the size of the page.


------------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions

 

[BoulderBum]

What is the nature of the data you're trying to persist through PostBacks? What is it's scope? Do you know the value you want to persist before the user visits the page?

If the data is sensitive, you should avoid sending it to the client via ControlState or ViewState and if the scope of the persisted data needs to be available beyond a certain Control or Page, then you'd want to consider other mechanisms. If you know the value of the variable you're trying to persist before a visit to the page, then QueryString is another option.

Knowing that, if the data you're storing isn't sensative, it's not known until the user visits the page, and you will only use the information for a specific Page or Control, then ViewState or ControlState is probably the correct choice.

MCP, MCTS - .NET Framework 2.0 Web Applications

 

[JurkMonkey]

I will be sending information like an address.

Can you elaborate on "other mechanisms" and what may be the best option? I have a php background and the concept of an event-driven page is a little new to me.

http://www.ubuntu.com/

 

[BoulderBum]

The breakdown of the scope of different fundamental storage mechanisms.

Request - data accessible during an HTTP request.
HttpContext.Items
Page/Control - data accessible during a page visit.
ViewState
ControlState
QueryString
Application - data accessible by all the application.
Application object
HttpRuntime.Cache
User - data accessible on a per-user basis.
Session
User Profile
Cookies

So let's say that your requirement is that you'd need to save a user's address and have it available on every page they visit, where it might appear on a header or something.

You'd want to consider the user-scoped mechanisms, so the main fundamental choices would be Session, User Profile, or Cookies. An address is personal information, so I'd probably shy away from persistant cookies, though session cookies might not be out of the question. Session would keep the address readily available at the expense of some overhead, and the user profile, through the default database storage, would persist the information for the user's next visit if that was desireable.

What's the best option out of those three? It depends. There's no rule that says "addresses always go here", rather you have to analyze your specific situation/requirements.



MCP, MCTS - .NET Framework 2.0 Web Applications