13

I have a list of type List<JobSeeker>. I want to store it in ViewState. How this can be done?

private List<JobSeeker> JobSeekersList { get; set; }
LoveFortyDown
  • 1,011
  • 2
  • 17
  • 37
user1613523
  • 963
  • 2
  • 7
  • 6

2 Answers2

23

Basically you only need to use the get , then on get you either get the posted data from view state, or set it for the first time on the view state. This is the more robust code to avoid all the checks on each call (is view state set, exist etc), and direct saved and use the view state object.

// using this const you avoid bugs in mispelling the correct key.
const string cJobSeekerNameConst = "JobSeeker_cnst";

public List<JobSeeker> JobSeekersList
{
    get
    {
        // check if not exist to make new (normally before the post back)
        // and at the same time check that you did not use the same viewstate for other object
        if (!(ViewState[cJobSeekerNameConst] is List<JobSeeker>))
        {
            // need to fix the memory and added to viewstate
            ViewState[cJobSeekerNameConst] = new List<JobSeeker>();
        }

        return (List<JobSeeker>)ViewState[cJobSeekerNameConst];
    }
}

Alternative to avoid the is

// using this const you avoid bugs in mispelling the correct key.
const string cJobSeekerNameConst = "JobSeeker_cnst";

public List<JobSeeker> JobSeekersList
{
    get
    {
        // If not on the viewstate then add it
        if (ViewState[cJobSeekerNameConst] == null)                
            ViewState[cJobSeekerNameConst] = new List<JobSeeker>();

        // this code is not exist on release, but I check to be sure that I did not 
        //  overwrite this viewstate with a different object.
        Debug.Assert(ViewState[cJobSeekerNameConst] is List<JobSeeker>);

        return (List<JobSeeker>)ViewState[cJobSeekerNameConst];
    }
}

and the JobSeeker class must be [Serializable] as

[Serializable]
public class JobSeeker
{
    public int ID;
    ...
}

and you simple call it normally as an object and will never be null. Also will be return the saved on viewstate values after the post back

JobSeekersList.add(new JobSeeker(){ID=1});
var myID = JobSeekersList[0].ID;
Aristos
  • 66,005
  • 16
  • 114
  • 150
  • Operators `as` and `!=null` are more efficient then `is` and `cast`. – abatishchev Nov 18 '12 at 06:29
  • @abatishchev @abatishchev Thank you for the note, I will check it out. How you define the `are more efficient` ? the code ether works ether not. Have more delay, more assembly runs ? can fail ? – Aristos Nov 18 '12 at 06:38
  • @abatishchev I read that article and "I do not see" why the `is` is not efficient in my case - I use it to double check if the object have been set, and if it is set then must be the same as the one I wont. Not the same case as the example on the page you give. – Aristos Nov 18 '12 at 08:32
3
private IList<JobSeeker> JobSeekersList
{
    get
    {
        // to do not break SRP it's better to move check logic out of the getter
        return ViewState["key"] as List<JobSeeker>;
    }
    set
    {
        ViewState["key"] = value;
    }
}
abatishchev
  • 98,240
  • 88
  • 296
  • 433
  • Well with this code, you need to double check if the list actually exist, or a post back done, then set it on the viewstate. What I mean is that here you also need to write more code on the handle of the JobSeekersList because you do not saved it on the viewstate as it is. – Aristos Nov 18 '12 at 06:33
  • @Aristos: I know but otherwise it will break Single Responsibility Principle - one method will perform both save and check, that isn't the best solution. So it's better to move the check logic out, and leave the property just to serve as a view state manager. – abatishchev Nov 18 '12 at 08:11
  • The "Principles" are for broken if they need to. If you like to save it to viewstate you need to not make any error and overwrite it, double check the ispost back, if exist, etc. By place it inside you avoid bugs. – Aristos Nov 18 '12 at 08:13
  • @Aristos: btw my initial code was performing such check. It just was using another operators for the same. But now I edited it to explicitly emphasize my point of view. – abatishchev Nov 18 '12 at 08:16
  • @Aristos: 2 different getter may have different "want": one want a list to be created, another doesn't. To avoid such situation you don't put any additional logic to the property and leave it lightweight and serving only one need. – abatishchev Nov 18 '12 at 08:18