Business object persistence on postback

Say I have a page in my web application that lets a user update their contact information. Pretend in order to retrieve or save this information I have the following class:

public class User
{
    DataAccesClass dataAccesClass = new DataAccesClass()
    public string UserName {get;set;}
    public string Address {get;set;}
    public string EmailAddress {get;set;}

    public User(){}

    public static User GetUser(int userI开发者_开发百科D)
    {
         User user = dataAccesClass.GetUser(userID); //
         return user;
    }

    public void Save()
    {
        dataAccesClass.SaveUser(this);
    }
}

Say that on my Page_Load event I create a new instance of my User class (wrapped in a !isPostBack). I then use it's public properties to populate text fields on said page in my web application. Now the question is... When the page is posted back, what is the correct way to rebuild this class to then save the updated information? Because the class was created on Page_Load !isPostBack event it is not available. What is the correct way to handle this? Should I store it in a Session? ViewState? Should I simply rebuild it every post back? The User class in this example is small so that might influence the correct way to do it but I'd like to be able to take the same approach for much larger and more complex classes. Also, would this class be considered an acceptable business object?

what is the correct way to rebuild this class to then save the updated information?

I would say the best practice would be do not rebuild the class on every postback. You should build the data on the first request, set values on controls, then let the viewstate on those controls persist the data.

If there is a potential for the data to need to be updated, tie re-generation of the object to an event indicating there is actual need to update.

Should I store it in a Session? ViewState? Should I simply rebuild it every post back?

Selecting whether to store the value in session or re-pull from the data layer should be based on the memory footprint of the object, the scalability requirements of the application, the costliness of the database operation, and the likelihood that the object will need to be accessed on any particular request. So I believe that is highly situational.

Also, would this class be considered an acceptable business object?

I don't have a lot of experience with BLL's but it looks like you're on the right track.

Unless profiling indicates otherwise, it's okay to just reconstruct the object with every request. You can also implement some kind of caching in your data access code. Your class is an acceptable business object.

Given that User object might have info you wouldn't want to expose through ViewState, it can be stored in Session.

This is the "standard" way of doing this in ASP.NET.

In the case of your example, reconstructing the object looks fine as it is small. But if you have a small object you inevitably store for a while, I would use session. If the object is large, I would directly use database or session with database connection.

Depending how complex you are thinking of getting a JavaScript framework called knockout.js might be a good fit. You could create a json object to bind to a jQuery template that would build the HTML depending on the object, it handles complex objects very well.