asp.net webforms - is this a good way of persisting state?

Question

This is a question about asp.net WebForms and sessionstate. I know this is probably a case where MVC is better, but I need to use WebForms.

In my page's OnLoad event, I initalize an object and its properties (one call to a db, then some logic for the properties.) I use this object to populate the controls on the page, eg. lblTitle.text = myObj.Title.

Also on this page is an input textbox, where the user will enter some info and then press a 'save' button. This will call a utility function which will write the contents of the textbox to a file and save it. Moreover, it needs to save it to a file with the name contained in myObj.Title.

Here's my problem - because of the stateless aspect of WebForms, after the page loads, myObj is gone.* Which means I can't do something easy like this on saving: Util.save(contentsoftextbox, myObj.Title).

So I solved it by writing the value of myObj.Title to a session variable (Session.Add["title"] = myObj.Title in the page's OnLoad event. Then when the save function is called, I use this session variable for my 2nd parameter.

Thanks for reading this far.

My question is:

This feels like a needlessly complex way of getting the job done. Is it? What else could I do to accomplish this task?

*right?

Answer 1

Have you looked at ViewState ? Might be a better option if you only need access to the object on the page you are on as opposed to keeping it in Session?

Answer 2

You could save it in the ViewState

Answer 3

That sounds like a fine way to do it overall. I don't know the details of your system, but maybe you should consider saving MyObj in session instead of just the title.

Answer 4

In most cases I would re-initialize myObj again on the postback.

Answer 5

Put the same value in a Input type=hidden. This way on the post back you will be able to read it back from it.

Placing such values on a session is a customary way, but it is better to avoid such route for many reasons related to maintaining session state on the server rather than on the browser, including but not limited to requiring session affinity (Session cookies, sticky sessions, etc.)

Answer 6

Beware of storing your objects in session. if you are not using In-proc, the object getting stored in session has to be serializable, so that it can scale.

Another option (if you want to store it on the client side and you dont care if the object is in plain text in the browser):You can use custom properties on your text box and serialize your object/property to JSON using JavaScriptSerializer

you can read more about HTML 5 Data Attributes here

Answer 7

Session works, but becomes troublesome in server farms. I avoid using session as much as possible.

I particularly dislike using session for page specific things like this as the value will probably never be removed from session if the user never completes the action on the page. A bunch of pages like that in the system and you soon have a very polluted session, and it's pretty easy to get bugs that act on session values that are simply leftover from some earlier actions.

Viewstate, will work and avoids the the session issues.

Reloading, the objects relevant to the page is often quite acceptable, and sometimes necessary for other reasons. Reloading is my preferred "default", though some objects may be too expensive to reload.

Simply placing the value in a hidden field, is much the same as using viewstate. For simple things like a single title I prefer hidden fields over viewstate as I like to keep everything as human readable as possible. However it is MUCH easier to tamper with a hidden field than with viewstate, so if hacking/security is a concern a hidden field is not a good choice.