G
Guest
It was not so difficult to figure this out:
George = Mark Broadbend = Kevin Spencer
George = Mark Broadbend = Kevin Spencer
K
Kevin Spencer
Hey, George, Mark, guess what? You're both me!
Hey Manny - do you program with that logic? You don't know where it's been!
--
ROFLMOD!
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
Hey Manny - do you program with that logic? You don't know where it's been!
--
ROFLMOD!
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
K
Kevin Spencer
Well, Wilbur, I love a good argument.
But this isn't one.
--
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
But this isn't one.
--
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
W
Wilbur Slice
Is too.
M
Mark Broadbent
Hey Manny, you are a genius! How long did it take you to figure this out.
Hey Kevin since I'm you can you hand me back my MVP so I can attach it to my
CV ....
oh I see George has already got it
Thanks Manny, not laughed this much since...... probably since your last
stupid stupid suggestion. Oh by the way try spelling my name right next time
buddy (although conceptually they are the same).
Hey Kevin since I'm you can you hand me back my MVP so I can attach it to my
CV ....
oh I see George has already got it
Thanks Manny, not laughed this much since...... probably since your last
stupid stupid suggestion. Oh by the way try spelling my name right next time
buddy (although conceptually they are the same).
P
Patrice
As always a trade off :
- using memory on the server vs passing back and forth data in the viewstate
It might be possible to well organize your code so that you can easily
swictch from one model to the other...
Patrice
- using memory on the server vs passing back and forth data in the viewstate
It might be possible to well organize your code so that you can easily
swictch from one model to the other...
Patrice
K
Kevin Spencer
Very clever, Mark. Pretending not to be me and/or George in order to confuse
Manny. And of course George already has it, since he's you! I mean Me! Or
perhaps we are all Uncle Chutney!
--
ROFLMOD,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
Manny. And of course George already has it, since he's you! I mean Me! Or
perhaps we are all Uncle Chutney!
--
ROFLMOD,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
M
Mark Broadbent
LMAO.
Now this is really gonna bake Manny's cookie.
I think we ought to come clean now :- Me and Kevin are one and the same, but
George is actually our brother (I mean MY brother).
Now brace yourself Manny old boy... Wilbur and Kris are actually our alter
ego's ..but hopefully we can keep them at bay long enough for this thread to
die
Now this is really gonna bake Manny's cookie.
I think we ought to come clean now :- Me and Kevin are one and the same, but
George is actually our brother (I mean MY brother).
Now brace yourself Manny old boy... Wilbur and Kris are actually our alter
ego's ..but hopefully we can keep them at bay long enough for this thread to
die
R
Richie Etwaru
Vish,
I found the following site to be helpful. Read it.
http://www.dotnetspider.com/technology/kbpages/832.aspx
As for the correct answer, architectural/technical choices are all about
"trade-offs". There are two many unknown variables for anyone to give
you a straight answer.
The gist is that if you understand the technical
implications/ramifications, the answer should be clear after some
discussion with you business and network/hardware folks.
Richie Etwaru
I found the following site to be helpful. Read it.
http://www.dotnetspider.com/technology/kbpages/832.aspx
As for the correct answer, architectural/technical choices are all about
"trade-offs". There are two many unknown variables for anyone to give
you a straight answer.
The gist is that if you understand the technical
implications/ramifications, the answer should be clear after some
discussion with you business and network/hardware folks.
Richie Etwaru
Web Applications are natively statesless, means once a web page renders from server to client, nothing remains on server and the next time user submits the page you have to create the page again.
Solutions in ASP.NET
ASP.NET provides multiple simple solutions to this problems like:
1- Viewstate
2- Session Variables
3- Application Variables
4- Cache
5- Cookies
Now the question arises that when to use what?
1- Viewstate
Viewstate is a hidden fields in an ASP.NET page, contains state of those controls on a page whose “EnableViewstate” property is “true”.
You can also explicitly add values in it, on an ASP.NET page like:
Viewstate.Add( “TotalStudents”, “87″ );
Viewstate should be used when you want to save a value between diferent roundtrips of a single page as viewstate of a page is not accessible by another page.
Because Viewstate renders with the page, it consumes bandwith, so be careful to use it in applications to be run on low bandwith.
2- Session Variable
Session variables are usually the most commonly used.
When a user visits a site, it’s sessions starts and when the user become idle or leave the site, the session ends.
Session variables should be used to save and retrive user specefic information required on multiple pages.
Session variables consumes server memory, so if your may have a huge amount visiters, use session very carefully and instead of put large values in it try to put IDs and references
3- Application variables
Application variables are shared variables among all users of a web application
Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.
4- Cache
Cache is probably the least used state feature of ASP.NET.
Cache is basically a resource specific state persistence feature, means unlike session it stick with resource instead of user, for instance: pages, controls etc.
Cache should be used or frequently used pages, controls, and data structures
Data cache can be used to cache frequently used list of values e.g. list of products
6- Cookies
Cookies are some values saved in browsers for a particular website o publicly accessible
The purpose of cookies is to help websites to identify visitors and retrieve their saved preferences
Cookies are also used to facilitate auto login by persisting user id in a cookie save in user’s browser
Because cookies have been saved at client side, they do not create performance issues but may create security issues as they can be hacked from browser
Finally remember the following points on your finger-tips:
1- Viewstate is bandwidth hungry
2- Session variables are memory hungry as per number of users
3- Applications variables are shared
4- Cache is memory hungry as per number of resources
5- Cookies are the least secure
http://devshop.wordpress.com/2008/04/10/how-to-choose-from-viewstate-sessionstate-cookies-and-cache
Solutions in ASP.NET
ASP.NET provides multiple simple solutions to this problems like:
1- Viewstate
2- Session Variables
3- Application Variables
4- Cache
5- Cookies
Now the question arises that when to use what?
1- Viewstate
Viewstate is a hidden fields in an ASP.NET page, contains state of those controls on a page whose “EnableViewstate” property is “true”.
You can also explicitly add values in it, on an ASP.NET page like:
Viewstate.Add( “TotalStudents”, “87″ );
Viewstate should be used when you want to save a value between diferent roundtrips of a single page as viewstate of a page is not accessible by another page.
Because Viewstate renders with the page, it consumes bandwith, so be careful to use it in applications to be run on low bandwith.
2- Session Variable
Session variables are usually the most commonly used.
When a user visits a site, it’s sessions starts and when the user become idle or leave the site, the session ends.
Session variables should be used to save and retrive user specefic information required on multiple pages.
Session variables consumes server memory, so if your may have a huge amount visiters, use session very carefully and instead of put large values in it try to put IDs and references
3- Application variables
Application variables are shared variables among all users of a web application
Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.
4- Cache
Cache is probably the least used state feature of ASP.NET.
Cache is basically a resource specific state persistence feature, means unlike session it stick with resource instead of user, for instance: pages, controls etc.
Cache should be used or frequently used pages, controls, and data structures
Data cache can be used to cache frequently used list of values e.g. list of products
6- Cookies
Cookies are some values saved in browsers for a particular website o publicly accessible
The purpose of cookies is to help websites to identify visitors and retrieve their saved preferences
Cookies are also used to facilitate auto login by persisting user id in a cookie save in user’s browser
Because cookies have been saved at client side, they do not create performance issues but may create security issues as they can be hacked from browser
Finally remember the following points on your finger-tips:
1- Viewstate is bandwidth hungry
2- Session variables are memory hungry as per number of users
3- Applications variables are shared
4- Cache is memory hungry as per number of resources
5- Cookies are the least secure
http://devshop.wordpress.com/2008/04/10/how-to-choose-from-viewstate-sessionstate-cookies-and-cache