Having attempted to convert a GET to POST using about half the available
xfer methods (and writing a whole lot of junk code in the process), here's
my opinion on page-to-page in .Net:
1. Don't use QueryString because a) all the variables are in the URL for
the world to see, and b) you are limited by the URL length limitation (we
have an app that hangs and eventually 404s(?) when using Response.Redirect
with long querystrings)
2. Don't use Context.Items. It seems to work, but because the item info
isn't actually persisted to either the page source (viewstate or POSTed
data) or the URL (QueryString), once the context is gone, the data is
lost, so if you go from page 1 to page 2 to page 3, and then backtrack to
page 1, the Context.Items for that page are lost forever. If it were
persisted in one of those other 3 ways, it would not be
3. Don't use Session. You'll run into some usenet posts where people
suggest that, but a) that isn't what the session is for, and b) it scales
horribly. Imagine the overhead on simply going from Page 1 to Page 2 via
Session var passing. Not too bad, since it's just some serialization of a
string, right? Change your state server to SQLServer and try now. Now
put that state server on a different machine and try again. Now add 4
machines to your IIS cluster. Try now. Session usage should be minimized
throughout your app, IMO, as you can't count on a full set of events (End
goes away in a cluster), and performance is tremendously variable based on
your particular server configuration, which itself is dynamic while your
compiled code is relatively static.
4. Don't use ViewState for transferring the information because there's
too much work you have to do on your end to get it the data in and out of
it (it's easier to reference the data than in #5), but it's not supposed
to be used for that anyway.
5. Use Server.Transfer, with the preserveForm parameter set to "true".
WHat that last part does is tell the system to keep the various ASP.Net
control fields in the POST header. So let's say Page 1 has "public
TextBox UserName;", if you say from page1, "Server.Transfer("Page2",
true)", from Page2, you have access to the value of UserName. The catch
is that the Request.Param key name is TextBox's UniqueID, NOT ID, so if
this control is within another control on your page,it will be
Request["ParentControl:UserName"]. I get around this by, upon
Page.PreRender, I call Page.RegisterHiddenInput("UserName",
Request["ParentControl:UserName"]). This method seems to solve most of
the issues, although figuring out a param name takes some computation + at
least in my case, the naming issues presented by UniqueID mean we have to
dump out an additional POST field, leading to twice the data getting
passed.
sstevens said:
Because of the postback architecture that was implemented with ASP.NET,
this
task is not as easy as it once was. If you need to pass data between
pages
there are several options:
1. Use querystring variables
2. Use session variables
3. Use application variables (careful, these are global)
4. Use Server.Transfer (this is may be what you are looking for, see
below)
Page 1
public class Page1 : System.Web.UI.Page
{
private void submitBtn_Click(object sender, System.EventArgs e)
{
//these can be public fields or public properties
//Creating public properties that get private fields
//is a better practice
lastName = "name1";
firstName = "name2";
Server.Transfer("page2.aspx");
}
}
Page 2
public class Page2 : System.Web.UI.Page
{
private void Page_Load(object sender, System.EventArgs e)
{
Page1 myPage1 = (Page1)Context.Handler;
string lastName = myPage1.lastName;
string firstName = myPage2.firstName;
}
}