Rather than using Session or view state, why don't we simply store the value as a variable to use later? What else does viewstate or session offer?

Question

Rather than using Session or view state, why don't we simply store the value as a variable to use later? What else does viewstate or session offer?

Answer 1

Hi @Bob Dang ,
Session is used to store information required for a specific user session. The introduction of the Session object is to make up for the insufficiency of the HTTP protocol, which is a stateless protocol.

Session means "session" in Chinese, and represents the "session" between the server and the client in ASP.NET. The action time of Session starts from the time when the user arrives at a specific Web page, and ends when the user leaves the Web site, or terminates a Session with code in the program. Referring to the Session allows a user to switch between multiple pages and also retain the user's information.

How do you store the value？ Simply as a variable? Other page don't know that.
Please read this article.

Best regards,
Yijing Sun

---

If the answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our  documentation  to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

The problem is that your variables don't exist RIGHT AFTER the page is rendered!!!

The way the web works?

Your code behind runs, variables are created. Your code updates controls on that page, and THEN the whole "web" page is sent down to the client side.

On the server side? Your page is gone, variables are deleted, all of the page now DOES NOT exist!!!!

The user now might un-plug their computer. They might click on their favorites bar, and jump to say www.bing.ca, and your page the again does not exist.

the page is created, sent to the browser. but the server side? it does not belong to any one user - does not even know if your page is done - or you turned of your computer. The web server JUST sits there - waiting for a web page to come in for processing. But, what web page comes (is posted) to the web server could be any page out of 100 users. Each page, and EACH TIME starts from scratch - starts from "zero", and the variables in that page do NOT exist!!!

The variables ONLY exist for what we call the page life cycle. So, we in effect have this:

When a web page is sitting on some far away users desktop? There is ZERO on the server side. You in effect have this:

From above, there is NO code or variables loaded on the server side.

When you click a button, then the page post-back starts. You get this:

So, you page travels up to the server.

You now have this:

Now, NOTE how I did NOT include the web page image on the left side. Whit it is true that the user STILL sees their page (they will see the "spin" or waiting icon).

So, your page is now on the server. The web page, code behind is loaded - STARTS FROM SCRATCH every time.
(and more important, the variables on the given page also start from scratch)

Now, your code runs, maybe modifies some controls on the page.

AND THEN the whole page is send back to the browser (client side). This is the so called round trip.

So, now after ALL of your code behind is done running, then the page travels back to client side:

On the server side, your WHOLE PAGE, and ALL OF the variables now again go out of scope, and in fact out of memory. The server is now just sitting there waiting for ANY web page to be posted - even others by the 25 other users on your side. There is ZERO concept of variables FOR ONE user.

So, RIGHT after that page is sent to the client side? The server dumps your page, dumps the code, dumps the variable(s) values. Remember, unlike 5 desktops, you have ONE web server, but it must serve MANY people, but it only one web server - not 5 separate computers like when running software on 5 desktops. You have ONE server, and it can only really deal with one incoming page at a time.

So, you can't just shove values into variables, since right after the page is send down to the browser, the server tossing out that page, the code, and the variables - that web server is now ready to process any web page from ANY other user - not necessary you!!!! As noted, the best way to think of this is what happens when you exit a subroutine call. Think of that whole page as a subroutine call - and one with only local variables - they go OUT of scope after the page is done rendering and sent back to the client side browser.

So, unlike your program running on 5 desktops, each desktop copy of your code can keep and have its own values. But with web based, you have ONE server.

It is sort of like how would your one desktop program run if you were to allow multiple users EACH to have a remote view of the one program. How could it serve many users? It could not.

The server side is still only one computer, and in fact is much like a single computer with ONE screen, but it has to web dish out pages to many users.

And once that page is sent to a user (client browser), then the server has no clue if you typing away on that page, closed the lid on your lap top, or maybe are now browsing off to some other web site - your server has no idea if that has occurred - the web page was dished out - the web server has done it job.

So, this why we call web development "state- less". By state-less, we mean the above. The web server can't really (much) distinguish between each user - since it is only one computer - and all it can do is dish out web pages.

So, if one user hits button, and the web page is posted back to the server? Then your whole page class loads again. It almost like calling a sub routine - but when you exit that sub-routine, all the local variables are GONE and out of scope. So, your variables ONLY exist during that short "round trip". Your variable values start from new or scratch EACH TIME your page code runs.

Same thing occurs to your web page. Once the page is done processing, then your code and variables now all go out of scope - almost as if you were exiting a sub routine.

You can VERY much think of your web page (and code behind) like a sub routine call - and one without global variables - but only local variables.
In fact, if you want global variables to the ONE user? Then you use session(). So, session() in a sense becomes your global variables - while the code behind and variables go out of scope EACH post back (even a simple button click is a round trip or so called post back). However, to deal with this issue, that is why you have session().

Session values = global to one user.
Viewstate = again to the one user, but ONLY per page.

And this should now make sense, since you ONLY have ONE web server, and it has to process web pages from all users - not just one users, and hence the code variables are local ONLY during the post-back, and when done, it in a sense exists the code - and all variables go out of scope.

If you want to keep "alive" or persist values - then you have to use session() - global to all your web pages, or use ViewState - only persists values to the one web page.

In effect, session() becomes your holding spot, or place for those variable values to "persist" or continue to exist for that one user after the page is sent back down to the client side.

So, if you have 50 users working on the web site, there are not 50 sets of the variables - but ONLY one set, and the code and variables ONLY exist during the processing, or what we common call round trip.

So, a real grasp of the architecture here is required when you jump into web land - it does not work at all like how desktop software works.

I hope above helps you grasp how a web server works.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada