By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,353 Members | 1,235 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,353 IT Pros & Developers. It's quick & easy.

ViewState, Application, Session....

P: n/a
ViewState["Name"] = "Bill";
-- This statement will send that to the browser and hash it into the
__VIEWSTATE hidden varible

Application["Name"] = "Bill";
-- This statement will keep this info on the server

Session["Name"] = "Bill";
-- This statement will keep this info on the server

Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?

Thanks
Ralph Krausse

www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg
Nov 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Ralph see below:
"Ralph Krausse" <go*******@consiliumsoft.com> wrote in message
news:49**************************@posting.google.c om...
ViewState["Name"] = "Bill";
-- This statement will send that to the browser and hash it into the
__VIEWSTATE hidden varible
True. But it will only be available between postbacks.

Application["Name"] = "Bill";
-- This statement will keep this info on the server
True. This will stay in memory for the lifetime of the application taking up
precious resources. Also, the variable will be available for the entire
application and requests for all sessions/users. Use this only if
necessary. Will not scale to Web Farm.


Session["Name"] = "Bill";
-- This statement will keep this info on the server
True. But also requires that browser accepts cookies to identify session
unless you use "cookieless sessions". This information is only available to
the session that sets it. This is mostly used to store user specific
information and will not be available to other user's sessions.


Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?
As you can see, it all depends on the situation. Normally you want to use
your application memory efficiently. So use application variables sparingly
and ensure to set a reasonble timeout value for your session variables.

- Frank Mamone


Thanks
Ralph Krausse

www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg

Nov 18 '05 #2

P: n/a
Some additions included below

Hans Kesting

"Frank Mamone" <fr**********@canada.com> wrote in message news:e7**************@tk2msftngp13.phx.gbl...
Ralph see below:
"Ralph Krausse" <go*******@consiliumsoft.com> wrote in message
news:49**************************@posting.google.c om...
ViewState["Name"] = "Bill";
-- This statement will send that to the browser and hash it into the
__VIEWSTATE hidden varible
True. But it will only be available between postbacks.


and:
* the lifetime is unlimited
* when the user uses the back-button, you will get a previous version

Application["Name"] = "Bill";
-- This statement will keep this info on the server
True. This will stay in memory for the lifetime of the application taking up
precious resources. Also, the variable will be available for the entire
application and requests for all sessions/users. Use this only if
necessary. Will not scale to Web Farm.


Session["Name"] = "Bill";
-- This statement will keep this info on the server


True. But also requires that browser accepts cookies to identify session
unless you use "cookieless sessions". This information is only available to
the session that sets it. This is mostly used to store user specific
information and will not be available to other user's sessions.


and the lifetime is limited to the session: if the session ends, the stored values
are gone

Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?


As you can see, it all depends on the situation. Normally you want to use
your application memory efficiently. So use application variables sparingly
and ensure to set a reasonble timeout value for your session variables.

- Frank Mamone


Thanks
Ralph Krausse

www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg


Nov 18 '05 #3

P: n/a
> Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?
The server is tired. It works too hard. Why not let the client (who only has
one user) handle a little of the work? Every time you pass off work to the
client, you save (work resources used * number of clients) resources on the
server.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Ralph Krausse" <go*******@consiliumsoft.com> wrote in message
news:49**************************@posting.google.c om... ViewState["Name"] = "Bill";
-- This statement will send that to the browser and hash it into the
__VIEWSTATE hidden varible

Application["Name"] = "Bill";
-- This statement will keep this info on the server

Session["Name"] = "Bill";
-- This statement will keep this info on the server

Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?

Thanks
Ralph Krausse

www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg

Nov 18 '05 #4

P: n/a
I will add to frank's reply.

ViewState:
one of the best things about ASP.NET's model is that everything is an
object. If you add a textbox the value, you can read the value again or the
modified value by doing textbox.Text;
how is that information available. A Dropdownlist has a listitems those list
items are available during postback cause the components store it in
viewstate and as a part of Request pipeline the framework initializes the
controls and reads the values into it without the user doing anything. If
you had a datagrid and there was a postback by someother object the datagrid
is unchanged. etc

with asp you had do read Request["variablename"] and do all the
processing.... viewstate tries to avoid developers going into the hassle.

Session: Session is a storage area that is specific to one user. the session
id is passed between all requests from client to the server using a http
header which identifies the session.
there are times when session provides a good way to store user specific
data. say you want to access same data in 10 pages and want to reduce the
number of database calls. or write to the localstorage. At that time you use
Session.

Application or Cache: (Use Cache in most instance)
Application and Cache objects are used to store non user specific global
data. if you want particular data items to be accessible to all users then
you store the object in Cache or Application.
Though if possible use Cache instead of Application. Cache is a cleaner way
to store data and it provides mechanism for object expiration and refresh
etc. Hogging the Application object can cause the worker process to restart.

Hope this helps

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)
"Ralph Krausse" <go*******@consiliumsoft.com> wrote in message
news:49**************************@posting.google.c om...
ViewState["Name"] = "Bill";
-- This statement will send that to the browser and hash it into the
__VIEWSTATE hidden varible

Application["Name"] = "Bill";
-- This statement will keep this info on the server

Session["Name"] = "Bill";
-- This statement will keep this info on the server

Is this all true? So why would one then send something to the browser
instead of easily keeping it on the server?

Thanks
Ralph Krausse

www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg

Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.