使用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

<html xmlns="http://www.w3.org/1999/xhtml" >
<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进行交互了，下面这个事件处理函数演示了如何获取源页面的标题并显示它：

if (PreviousPage != null)
{
lblInfo.Text = "You came from a page titled " + PreviousPage.Header.Title;
}

注意：该方法在访问PreviousPage对象前先对其作了null检查，如果结果为false，表明没有跨页面提交发生，也就是说，CrossPage2.aspx是被直接请求的，或者由其自身提交，此时PreviousPage对象不可用。

从源页面中获取更多数据

上面那个示例作了一个有趣的尝试，但仅仅如此，我们还是不能传递任何有用的信息。

要获取源页面中控件的值，可以使用FindControl方法：

if (PreviousPage != null)
{
    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类）：

if (PreviousPage != null)
{
    CrossPage1 prevPage = PreviousPage as CrossPage1;
    if (prevPage != null)
    {
        // 此时可以访问源页面的公共属性
    }
}

另外，除了在代码中进行类型转换，还可以在.aspx页面中添加PreviousPageType指示字：

<%@ PreviousPageType VirtualPath="~/CrossPage1.aspx" %>

此时，PreviousPage属性会自动使用CrossPage1类型，编辑器中的智能提示也可以使用了。但是这种方法相当脆弱，因为你只能使用一个页面类！因此，出于灵活性考虑，使用类型转换的方法会更好。

好了，不管怎样，现在已经将PreviousPage对象转换为合适的页面类型了，但是你还是不能直接访问它包含的控件对象。这是因为这些控件都被声明为保护类型(protected)，此时的解决方案是使用属性。

比如，如果希望公开源页面上两个文本框控件的值，可以添加属性来封装控件对象，如在CrossPage1类中添加属性：

public TextBox FirstNameTextBox
{
get { return txtFirstName; }
}

public TextBox LastNameTextBox
{
get { return txtLastName; }
}

但是，这通常不是最好的方法。其问题在于它公开了太多的细节，目标页面可以读取文本框控件的所有内容了。如果过段时间需要修改源页面，决定使用不同的输入控件，维护这些属性就相当困难了，因为你不得不修改两个页面的代码。

更好的方法是定义更具体的属性，它们应当仅仅提供你需要的东西。比如，你可以考虑添加一个FullName属性，该属性读取两个文本框的值：

public string FullName
{
get { return this.txtFirstName.Text + " " + this.txtLastName.Text; }
}

这样做，两个页面的关系就变得清晰、简单并易于维护了。如果你决定在CrossPage1中使用新的输入控件，只要修改CrossPage1页面就好了。CrossPage2中的代码也相应地修改如下：

if (PreviousPage != null)
{
    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的最终结果：

跨页面提交确实非常有用，但它们也会使页面变得复杂。如果你允许多个源页面提交到同一目标页面，你就得编写代码逻辑以判断页面来自何处，然后作出相应处理。要避免这种烦恼，简单的方法就是只在两个特定的页面间使用它。

By Anders Cui

参考：
Beginning.ASP.NET.2.0.in.C.Sharp.2005.From.Novice.to.Professional by Matthew MacDonald