I Don't Like Server.Transfer()

  • Thread starter Thread starter senfo
  • Start date Start date
S

senfo

In my not so humble opinion, Server.Transfer() looks good on paper, but
I have yet to come across a use for it that couldn't be accomplished
better another way. When it comes down to it, I really dislike the
method because, at least at my company, it leads to bad designs. It
also further irritates end users because it breaks the back button. I
really wish the Server.Transfer() method would go away so people would
stop using it.

What do the rest of you think?
 
Like anything, only use something when it is appropriate. If it is more
appropriate to you to use Redirect then do so. I use Transfer when
implementing my own handlers so that the user's URL remains what they think
it is while the page they are viewing is something else.
 
Aidy said:
Like anything, only use something when it is appropriate. If it is more
appropriate to you to use Redirect then do so. I use Transfer when
implementing my own handlers so that the user's URL remains what they think
it is while the page they are viewing is something else.
Click to expand...

If I don't want my URL to change between postbacks, I just implement
panels and set their Visible property as appropriate. That way I have
*direct* access to the controls on their values.
 
senfo said:
That way I have *direct* access to the controls on their values.
Click to expand...

Erg...Should have read my post before submitting it! That should have
read, "controls and their values", not "on".
 
If I don't want my URL to change between postbacks, I just implement
panels and set their Visible property as appropriate. That way I have
*direct* access to the controls on their values.
Click to expand...

It's not that I want the URL to remain the same, I want "user friendly" page
names that hide ?ID=123456 type affairs.

Besides, putting everything on one page in panels would be a nightmare to
maintain. You'd be better off using a FRAME.
 
Aidy said:
It's not that I want the URL to remain the same, I want "user friendly" page
names that hide ?ID=123456 type affairs.

Besides, putting everything on one page in panels would be a nightmare to
maintain. You'd be better off using a FRAME.
Click to expand...

Not true, at all. And frames are an outright horrible design, but
that's another topic, altogether.

For a search page, I almost always have the input controls on a
Search.aspx page and then pass search criteria through a query string to
a SearchResults.aspx. It makes it easy to bookmark and also makes
scaling much easier. If, however, I didn't want to use a QueryString
for whatever reason, I'd just POST the values to the SearchResults.aspx
page and access them through the PreviousPage property.

For a page that adds a new record to a database and then displays a
confirmation (e.g, a sign up page), I'd most likely provide multiple
panels that I can either hide or show. The initial SignUp.aspx page,
for example, would display all the controls necessary to sign up for my
site. After a user clicks the "Submit" button, I'd hide the original
panel and display only the conformation. It simply makes sense, to me,
that the confirmation be contained within the same page. I could have
used Server.Transfer() and transfered to a page that had the
confirmation in the HTML, but that just wouldn't be as clean. Now if
you've got 10+ panels on your page and you need 1,000 lines of code to
determine which panel should be displayed, you probably should look into
splitting the panels up into multiple pages.

These are obviously two simple examples, but they scale quite nicely and
it's amazing how often I play on these two ideas with only a slight
variation.

Like I said before, I have yet to find any site that uses
Server.Transfer() that couldn't have accomplished the same concept more
cleanly using an alternative. It simply creates more problems than it
solves.
 
Peter said:
If you don't like Server.Transfer, nobody is holding a gun to your head. :-)
Peter
Click to expand...

It's not really so much me (I avoid using it), it's that I see it used
time and time again on sites I've maintained. Every single time I've
run across it, there was some kind of issue that it was creating that
ultimately left me with having to resolve it by moving to an
alternative. To me, it's such a bad idea to begin with that I wish it
would be removed from ASP.NET, altogether, to prevent *other* people
from using it.
 
Like I said before, I have yet to find any site that uses
Server.Transfer() that couldn't have accomplished the same concept more
cleanly using an alternative. It simply creates more problems than it
solves.
Click to expand...

And as I said, I have a site that uses it for a form of URL rewriting.
However I admit it is the only time I've used it. To suggest it is removed
just cos you've never found a use for it is silly, if not arrogant. I can
still see where it can be useful for other people (let's say you want to
split processing across three pages, you could Transfer between them and
Redirect on the last page), just cos I've rarely done something that uses it
I can appreciate its value.

If you don't need it, don't use it.
 
Back
Top