querystring pros and cons, help?

[Guest]

Hi folks,
I'm having a discussion with my colleague about how to go about passing data
from one aspx page to another
example
On the main page I have a whole list of relationship managers with a
hyperlink that says 'customers' in each row for each manager and the
hyperlink contains a parameter for that manager and when the 'customers' page
is opened it checks that parameter via its querystring property

is this a bad thing to do?

is there a more generally well regarding method of passing the ID of that
manager to the 'Customers.aspx' page

I think that querystrings are a perfectly respectable way to do this, my
colleague thinks that it will be slow and inelegant (and is mentioning things
such as server.transfer, server.redirect, which I don' t think are to do with
this kind of typical scenario)

any suggestions would be welcome!

thanks in advance for your help
CharlesA

 

[Guest]

I believe a querystring parameter is OK for this scenario. Make sure you take
malicious use of the querystring into account, I normally encrypt these
parameters and give them meaningless names like p1 rather tha ManagerID

HTH

David

 

[Karl Seguin [MVP]]

The biggest problem with a querystring value is security, both in the sense
that it can't be used to pass secure information around and it can be
tampered. What if you don't want anyone to be able to put any ID in the
querystring? Of course, chances are you'd have a check on customer.aspx for
that anyways.

i think your colleague is dead wrong about performance. Querystrings tend to
be the most performant (did you know that isn't actually a word?) solutions.

With a querystring you have a link that goes to a different page
customer.aspx?id=3 It will result in a typical GET, RESPONSE scenario.

To get server.transfer going, you are going to need to postback to the page
you are currently on and do the server.transfer. The postback itself is a
GET, RESPONSE and the server.transfer happens internally. The net result is
that this mechanism is the exact same for the client (oh, except they can't
bookmark the page they are now on), but on the server you've now had 2
init's, loads, 1 loadviewstate and rebuilt all the controls of the first
page just to hook into the event.

Sometimes you need to postback, say to finish some tasks before "leaving"
the page. Sometimes the power of storing values in the HttpContext and doing
a Transfer is absolutely necessary. But from the simple case you've
described, security concerns aside, querystring all the way.

Karl

 

[Guest]

I think that querystrings are a perfectly respectable way to do this,
my colleague thinks that it will be slow and inelegant (and is
mentioning things such as server.transfer, server.redirect, which I
don' t think are to do with this kind of typical scenario)

There are a couple ways to pass data between pages in ASP.NET:

Session Variables
Context Cache Variables
Querystring Variables
Cookies

Here's what I think:

Querystring are simple and allow bookmarking of the page.

Session Variables should be used to transfer larger pieces of data (i.e.
object data).

Context Cache variables is another option. They allow passing of data
between pages for 1 request (afterwards the context cache is cleared).
However, Context cache variables must use Server.Transfer. While
Server.Transfer technically is more efficent than a Reponse.Redirect, the
end user does not see the page address change - thus the end user cannot
bookmark the page.

In your situation, I agree with you... Query Strings are nice and simple,
unless you're passing a bunch of data.

 

[Karl Seguin [MVP]]

I find a bit of this misleading.

Session variables aren't associated to size of data ("larger pieces"), but
rather time to live. They live throughout the entire visit, not a single
request. You don't use a session because there's a lot of data, you use it
'cuz you need it alive for the duration of the visit. Personally, I woudln't
even use it there, as it pins it in memory, I'd store it in the cache with a
userId key.

I think what you mean by Context Cache is actually the Context Items
collection. I only point that out because I think when most people hear
"cache" they think of the Cache object (which is available via the context,
Context.Cache).

Karl

 

[Guest]

Thanks everyone for your speedy and helpful posts
much appreciated, especially the breadth and as I say again the speed with
which you all answered!

many thanks
CharlesA

to Karl, I didn't know that 'perfomant' wasn't a word, I've been using it
ever since I went to an incredibly interesting lecture by Ingo Rammer in
which he said that business objects are way more 'performant' than Datasets
in remoting scenarios...

 

[Karl Seguin [MVP]]

That's ironic, I think I first found out when writing my article on business
objects vs datasets for MSDN My girlfriend poitned it out (she's my
first editor) and I had to rewrite some stuff because of her. I've since
reverted to using it!

http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

Some trace it to the french word spelt the same meaning "efficient"