Session vs QueryString

[dbarker1]

This may be a can of worms but I wanted to throw it out here. I am
gathering pros and cons for using querystring vs session variables for
passing row keys in a ASP.net application. I want to be as thorough as
possible so why not throw out this situation to the development
community. Thoughts and opinions are appreciated.

 

[Steven Nagy]

Its easy to forget to remove the key from session once its usability
has passed.
I figure that session is for keeping information long term over some
substantial life time, such as tracking that a user is logged in.

Querystring is fine for page by page stuff, but there's also the
Viewstate and Cache considerations as well. I don't think you can weigh
up such an argument without including these 2 forces of nature.

Steven

 

[Steve C. Orr [MVP, MCSD]]

Querystrings are editable by users. This can sometimes be a good thing for
knowledgeable users, however you must carefully think about the security
implications if users go tinkering with the querystring parameters.

Querystrings are visible by users. This can be a good thing in cases where
the user saves a URL in their favorites, because it can potentially also
save the state too, assuming you're keeping state in the querystring.
However this can be bad if retrieving the querystring from their favorites
causes your app to throw an error, then the user is left looking at an
unfriendly error page instead of the page they thought they'd bookmarked.

Session strings are more reliable and secure because they are always kept on
the server and never visible or editable by users. The main downside to
session variables is that each one takes up space in server memory, thus
limiting the scalability of the site. (However there are ways to deal with
this such as using a SQL state server or a centralized state server.)

Don't forget about other alternatives, such as the context object, cookies,
saving to a database, hidden fields (to help post data between forms), etc.

Here are some good articles on the subject:
http://SteveOrr.net/faq/PassValues.aspx
http://www.aspalliance.com/kenc/passval.aspx
http://msdn.microsoft.com/msdnmag/issues/03/04/ASPNETUserState/default.aspx

 

[Phil H]

For what it's worth I dont think that you can realisitically compare
one with the other as though they always represent a straight choice.
There are circumstances when one or the other may be the only viable
solution.

To give some examples. I recently developed an application that created
tables of data (with a layout that couldn't be supported by a DataList)
where each cell needed to contain a server control to initiate a
postback with a parameter that would be used to retrieve data from a
database. As the controls were being created programatically and there
were many of them, I couldn't use link buttons because I had know way
of creating an event handler on the fly. The solution here for me was
to use hyperlinks that pointed back to the same page with the parameter
in a query string, which could be created programatically and detected
easily as part of the page load event. I don't see how this could have
been achieved using Session state variables.

On another occasion I could'nt use a query string without making the
coding of the page load event over complicated. This was caused by the
fact that a page request using a query string doesn't initiate a
postback event (so IsPostBack is always false) and so you have to
differentiate between an initial page request and a repeat one.

 

[Edwin Knoppert]

I made myself a common function which moves a session variable to the
viewstate on page load.
This means i only use it for passing data from one page to another and
release the session var imm.
If needed i simply put it on the session again and jump to another page.
Of course, these target pages must be aware of this singkle item but that's
how i do it.

Once you have such a function it all becomes very handy.

On each postback it verifies if the session var exists and 'updates' a
private variable which is of course 0 on first load.
You can ommit this since it's a postback but i dont' mind.

 

[Mark Rae]

I made myself a common function which moves a session variable to the
viewstate on page load.
This means i only use it for passing data from one page to another and
release the session var imm.
If needed i simply put it on the session again and jump to another page.
Of course, these target pages must be aware of this singkle item but
that's how i do it.

I do pretty much exactly the same...

 

[sloan]

If my primary key is a guid, then I use querystring.

If my primary key is an int, I go to the Session route.

EmpID=123 is too easy to change to EmpID = 124 ......in my world.

http://sholliday.spaces.live.com/?_...gview&_c=blogpart&partqs=amonth=10&ayear=2005

I have a Session Wrapper object.

On the page1, I put a small object into my wrapper object.
On page2, I have both an indexer and .Remove method. I use the .Remove
method. That way I get the value, but don't orphan it.

The object I put into the SessionWrapper is small. Usually just an int.

I also have an abstract class, which I inherit from. The abstract class has
"EditMode" ... which is an enum with 2 values. AddNew and Edit(Existing)

This way, I can decide on the SomethingEdit.aspx page.... whether I'm adding
a new one or editing an existing one, without a bunch of weirdo logic saying

if (empid == null) || (empid<=0)

I have an enum value which tells me.

.......

If I was edting an employee. I'd extend the abstract class, and add an EmpID
property

EmpArg : MyBaseEditModeClass
--EditMode
--EmpId


Anyway. Its a little complex at first, but I like it.

If youre using guids

EmpEdit.aspx?empuuid=0E139585CE5542d985098C7898FB4CF8

Then odds are, no one is going to guess another empuuid

 

[Edwin Knoppert]

Sessions expire, viewstates not..

If my primary key is a guid, then I use querystring.

If my primary key is an int, I go to the Session route.

EmpID=123 is too easy to change to EmpID = 124 ......in my world.

http://sholliday.spaces.live.com/?_...gview&_c=blogpart&partqs=amonth=10&ayear=2005

I have a Session Wrapper object.

On the page1, I put a small object into my wrapper object.
On page2, I have both an indexer and .Remove method. I use the .Remove
method. That way I get the value, but don't orphan it.

The object I put into the SessionWrapper is small. Usually just an int.

I also have an abstract class, which I inherit from. The abstract class
has
"EditMode" ... which is an enum with 2 values. AddNew and Edit(Existing)

This way, I can decide on the SomethingEdit.aspx page.... whether I'm
adding
a new one or editing an existing one, without a bunch of weirdo logic
saying

if (empid == null) || (empid<=0)

I have an enum value which tells me.

......

If I was edting an employee. I'd extend the abstract class, and add an
EmpID
property

EmpArg : MyBaseEditModeClass
--EditMode
--EmpId


Anyway. Its a little complex at first, but I like it.

If youre using guids

EmpEdit.aspx?empuuid=0E139585CE5542d985098C7898FB4CF8

Then odds are, no one is going to guess another empuuid

 

[dbarker1]

Everyone,

Excellent information. I appreciate everyones responces. The
Microsoft article above is a good read.

Thanks all