使用Cross-Page Postback(跨页面提交)在页面间传递数据
在页面间传递数据时，我们有以下几种选择：
1、Query String
一个很常见的方法，Query String是URL中问号之后的那一部分。其优点在于它是轻量级的，不会给服务器带来任何负担。而它也有几个缺点：传递的信息仅限于简单的字符串，而且必须是合法的URL字符；信息是对用户是可见的，因而存在安全性问题；用户可能会尝试手动修改查询字符串，这可能是程序未预料到或不能防范的；很多浏览器对URL的长度都有所限制（通常为1KB到2KB）。
2、Cookie
Cookie是创建在客户端硬盘上（或者，如果它们是临时的，则在内存中）的小文件。其优点在于使用时不易被用户察觉，可被程序中每个页面使用，并且可将数据长期保存。但它也有一些与Query String 相同的缺点：仅限于简单的字符串信息；一旦用户找到了相应的文件，它们也是易于访问和阅读的。所以Cookie最好不要用于保存复杂的或私密的信息。
3、Session
可以在源页面中将数据保存在Session中，然后在目标页面中读取这些数据。注意：将大量的信息存储在Session中会严重影响服务器的性能。
4、Server.Transfer
要进行服务器端的重定向，可以使用Server.Transfer。因为在服务器端执行，Server.Transfer方法不需要请求另一页面。使用HttpContext，我们可以在目标页面中访问源页面中的数据。其缺点是，浏览器并不了解返回给它的是另外一个页面，它在地址栏中会显示第一个页面的URL，这会让用户陷入混乱，在他们使用书签的时候也会产生麻烦。所以不推荐该方法。
5、其它
还可以使用缓存（Cache）来存储数据，可在程序的任意处访问缓存。建议仅对那些修改不太频繁但经常使用的数据使用缓存。 另外在某些特定情况下还可以使用Application变量，如统计页面的点击数等。
使用Cross-Page Postback
ASP.NET 2.0中引入了一个新的方法：跨页面提交，即postback触发在另一个页面。这种技术听起来很是简单，但却存在隐患。一不小心，就会导致你创建的页面紧密耦合，难以维护和调试。
支持跨页面提交的机制是一个名为PostBackUrl的属性，该属性由IButtonControl接口定义，实现这个接口的按钮控件包括ImageButton，LinkButton，Button。将PostBackUrl属性值设置为另一个web窗体的名称（即URL），当用户点击按钮时，页面将被提交到新的URL。
看下面这个示例，该示例包括源页面CrossPage1.aspx和目标页面CrossPage2.aspx：
CrossPage1.aspx
< head runat ="server" >
< title > Source Page </ title >
</ head >
< body >
< form id ="form1" runat ="server" >
< div >
FirstName: < asp:TextBox runat ="server" ID ="txtFirstName" ></ asp:TextBox >
< br />
LastName: < asp:TextBox runat ="server" ID ="txtLastName" ></ asp:TextBox >
< br />
< asp:Button runat ="server" ID ="cmdSubmit" PostBackUrl ="~/CrossPage2.aspx" Text ="Cross-Page Postback" />
</ div >
</ form >
</ body >
</ html >
CrossPage1.aspx不包含任何代码，效果如下：
现在点击按钮，该页面就被提交到CrossPage2.aspx了。此时CrossPage2.aspx页面可以使用Page.PreviousPage属性与CrossPage1.aspx进行交互了，下面这个事件处理函数演示了如何获取源页面的标题并显示它：
{
lblInfo.Text = " You came from a page titled " + PreviousPage.Header.Title;
}
注意：该方法在访问PreviousPage对象前先对其作了null检查，如果结果为false，表明没有跨页面提交发生，也就是说，CrossPage2.aspx是被直接请求的，或者由其自身提交，此时PreviousPage对象不可用。
从源页面中获取更多数据
上面那个示例作了一个有趣的尝试，但仅仅如此，我们还是不能传递任何有用的信息。
要获取源页面中控件的值，可以使用FindControl方法：
{
lblInfo.Text = " You came from a page title " + PreviousPage.Header.Title;
string firstName = (PreviousPage.FindControl( " txtFirstName " ) as TextBox).Text;
string lastName = (PreviousPage.FindControl( " txtLastName " ) as TextBox).Text;
lblInfo.Text += " <br /> " ;
lblInfo.Text += " your full name: " + firstName + " " + lastName;
}
要获得更多信息，我们需要将PreviousPage引用转换为适当的页面类（本示例中是CrossPage1类）：
{
CrossPage1 prevPage = PreviousPage as CrossPage1;
if (prevPage != null )
{
// 此时可以访问源页面的公共属性
}
}
另外，除了在代码中进行类型转换，还可以在.aspx页面中添加PreviousPageType指示字：
<%@ PreviousPageType VirtualPath="~/CrossPage1.aspx" %>
此时，PreviousPage属性会自动使用CrossPage1类型，编辑器中的智能提示也可以使用了。但是这种方法相当脆弱，因为你只能使用一个页面类！因此，出于灵活性考虑，使用类型转换的方法会更好。
好了，不管怎样，现在已经将PreviousPage对象转换为合适的页面类型了，但是你还是不能直接访问它包含的控件对象。这是因为这些控件都被声明为保护类型(protected)，此时的解决方案是使用属性。
比如，如果希望公开源页面上两个文本框控件的值，可以添加属性来封装控件对象，如在CrossPage1类中添加属性：
{
get { return txtFirstName; }
}
public TextBox LastNameTextBox
{
get { return txtLastName; }
}
但是，这通常不是最好的方法。其问题在于它公开了太多的细节，目标页面可以读取文本框控件的所有内容了。如果过段时间需要修改源页面，决定使用不同的输入控件，维护这些属性就相当困难了，因为你不得不修改两个页面的代码。
更好的方法是定义更具体的属性，它们应当仅仅提供你需要的东西。比如，你可以考虑添加一个FullName属性，该属性读取两个文本框的值：
{
get { return this .txtFirstName.Text + " " + this .txtLastName.Text; }
}
这样做，两个页面的关系就变得清晰、简单并易于维护了。如果你决定在CrossPage1中使用新的输入控件，只要修改CrossPage1页面就好了。CrossPage2中的代码也相应地修改如下：
{
lblInfo.Text = " You came from a page titled " + PreviousPage.Header.Title + " <br /> " ;
CrossPage1 prevPage = PreviousPage as CrossPage1;
if (prevPage != null )
{
lblInfo.Text += " You typed in this: " + prevPage.FullName;
}
}
下面是CrossPage2的最终结果：
跨页面提交确实非常有用，但它们也会使页面变得复杂。如果你允许多个源页面提交到同一目标页面，你就得编写代码逻辑以判断页面来自何处，然后作出相应处理。要避免这种烦恼，简单的方法就是只在两个特定的页面间使用它。