ASP.NET 2.0 中的新增服务、控件与功能概述(四)

原文出自http://blog.sina.com.cn/s/blog_48b6cd65010004fc.html

个性化

另一个新增的服务是个性化，它提供了一种现成的解决方案，用于解决存储站点用户的个性化设置问题。目前，此类设置通常存储在Cookie、后端数据库或这两者中。无论这些设置存储在何处，ASP.NET 1.x都不能提供什么帮助。这需要由您来设置和管理后端数据存储，以及使用经过身份验证的用户名、Cookie或其他某种机制来关联个性化数据。

ASP.NET 2.0个性化服务使得存储各个用户的设置以及随意检索这些设置变得非常容易。该服务基于用户配置文件—您可以使用新的元素在Web.config中予以定义。下面的代码节选自Web.config：

它定义了一个包含三个属性的配置文件：一个名为Theme的字符串，一个名为Birthday的DateTime值，以及一个名为LoginCount的整数。后面这个属性被赋予默认值0。

在运行时，您可以使用页面的Profile属性（该属性引用包含该配置文件中定义的属性的动态编译类的实例）来访问当前用户的这些属性。例如，下列语句可从当前用户的配置文件中读取属性值：

string theme = Profile.Theme;
DateTime birthday = Profile.Birthday;
int logins = Profile.LoginCount;

还可以将值赋予配置文件属性：

Profile.Theme = "SmokeAndGlass";
Profile.Birthday = new DateTime (1959, 9, 30);
Profile.LoginCount = Profile.LoginCount + 1;

个性化服务的一个明显优势是强类型化。另一个优势在于个性化数据是按需读写的。请将此与会话状态（无论是否使用，都会将其加载并保存到每个请求中）进行对比。但是，个性化服务的最大优势可能在于您不必显式地将数据存储在任何位置；系统会替您完成该工作，并且它会永久性地存储数据，以便数据在您需要时随时可用。配置文件不会像会话那样超时。

那么，个性化数据存储在哪里呢？这要依具体情况而定。个性化服务基于提供程序，因此您可以将其配置为使用任何可用的提供程序。ASP.NET 2.0将至少附带两个个性化提供程序：一个用于Access，另一个用于SQL Server。如果您不另行指定，则个性化服务将使用Access提供程序，默认情况下，该提供程序会将个性化数据存储在本地Data\AspNetDB.mdb中。您可以通过修改Web.config（手动或使用Webadmin.axd）来改用SQL Server数据库。如果您不希望将个性化数据存储在Access数据库或SQL Server数据库中，则可以编写自己的提供程序。

默认情况下，ASP.NET使用经过身份验证的用户名作为所存储的个性化数据的键，但您也可以将其配置为支持匿名用户。首先，通过将以下语句添加到Web.config中来启用匿名标识：

然后，将allowAnonymous="true"添加到您要为匿名用户存储的配置文件属性中：

<name="Theme" allowAnonymous="true" />

现在，Theme属性可以作为个性化设置使用，而无论站点的调用方是否经过了身份验证。

默认情况下，匿名标识使用Cookie来标识回返用户。由支持的属性可以用各种方式来配置这些Cookie。例如，您可以指定Cookie名称，并指明是否应该将该Cookie的内容加密。您还可以将个性化服务配置为使用无Cookie的匿名标识，因此它将依靠URL Munging来标识回返用户。甚至还存在一个自动检测选项：如果请求浏览器支持Cookie，则使用Cookie；如果不支持，则使用URL Munging。

要查看个性化的工作方式，请运行本文随附的下载资料中的Personalize.aspx示例。它会让站点的每个访问者选择一个主题，然后记录该主题，并且每当该访问者返回时都将应用该主题。请注意，该主题是在页面的PreInit事件（它是一个新事件，它的激发时间甚至早于Init）中以编程方式应用于该页面的。

在您运行该示例之前，需要启用匿名标识，并定义一个包含名为Theme的字符串属性的配置文件。以下代码行显示了执行上述两项任务的Web.config文件：

SQL缓存依赖性

ASP.NET 1.x中令人遗憾地缺少的另一项功能是数据库缓存依赖性。可以将ASP.NET应用程序缓存中放置的项目与其他缓存项目联系起来，或者与文件系统中的对象联系起来，但不能与数据库实体联系起来。ASP.NET 2.0通过引入SQL缓存依赖性来纠正这一由于疏忽而造成的错误。

SQL缓存依赖性由新的SQLCacheDependency类的实例表示。它们的用法非常简单。下面的语句将一个名为ds的数据集插入到应用程序缓存中，并且在该数据集和Northwind数据库的Products表之间创建依赖性：

Cache.Insert ("ProductsDataSet", ds,
new SqlCacheDependency ("Northwind", "Products");

如果Products表的内容改变，则ASP.NET会自动删除该数据集。

SQL缓存依赖性还可以与ASP.NET输出缓存配合使用。下面的指令指示ASP.NET缓存来自包含页面的输出，直至Products表的内容改变或者满60秒为止（满足任一条件即可）：

<%@ OutputCache Duration="60" VaryByParam="None"
SqlDependency="Northwind:Products"
%>

SQL缓存依赖性适用于SQL Server 7.0、SQL Server 2000和即将问世的SQL Server 2005。对于SQL Server 2005，无需进行任何准备；但必须将SQL Server 7.0和SQL Server 2000数据库配置为支持SQL缓存依赖性。准备工作涉及到创建数据库触发器，以及创建一个特殊的表，以供ASP.NET在确定是否已经发生更改时参考。该表由一个后台线程使用可配置的轮询间隔（默认为5秒钟）来定期轮询。在SQL Server 2005中，要检测更改，既不需要特殊的表，也不需要轮询。此外，SQL Server 2005缓存依赖性可以在行级应用，而SQL Server 7.0和SQL Server 2000缓存依赖性在表级工作。您可以使用Aspnet_regsqlcache.exe工具或Webadmin.axd来准备数据库，以使其支持SQL缓存依赖性。

新的动态编译模型

ASP.NET 1.x中引入的众多创新之一是：系统能够在首次访问您的代码时对其进行编译。但是，只有页面能够被自动编译，并且辅助类（如数据访问组件）必须单独编译。

ASP.NET 2.0扩展了动态编译模型，以便能够自动编译几乎所有的组件。bin目录仍然保留以便实现向后兼容性，但它现在添加了名为Code和Resources的目录。Code目录中的C#和Visual Basic文件以及Resources目录中的RESX和RESOURCE文件被ASP.NET自动编译并缓存在系统子目录中。此外，落入Code目录中的Web服务描述语言(WSDL)文件被编译为Web服务代理，而XML架构定义语言(XSD)文件被编译为类型化数据集。通过Web.config，还可以扩展这些目录以支持其他文件类型。

预编译并且在不带源代码的情况下进行部署

提到动态编译，与ASP.NET 1.x有关的最常见问题之一是：是否可以预编译页面，以避免在首次访问页面时发生的编译延迟？尽管该问题本身在某种程度上无关紧要（延迟非常小，并且延迟的开销被成千上万甚至数以百万的后续请求所分摊），但Microsoft仍然感到有必要采取相应的措施来减轻开发人员的担忧。这一“措施”就是能够通过提交对名为precompile.axd的幻像资源的请求，来预编译应用程序中的所有页面。

但预编译并不仅限于此。另一个经常被请求的功能是：能够将整个应用程序预编译为可以在不带源代码的情况下进行部署的托管程序集（该功能在宿主方案中尤其有用）。ASP.NET 2.0包含一个名为Aspnet_compiler.exe的新的命令行工具，它能够执行预编译并且在不带源代码的情况下进行部署；Visual Studio 2005将包含类似的功能。下面的命令将预编译Web1目录中的应用程序，并且在不带源代码的情况下将其部署到Web2：

Aspnet_compiler -v /web1 -p c:\web1 c:\web2

之后，目标目录将包含空的ASP.NET文件（ASPX、ASCX、ASIX等等）以及源目录中存在的所有静态内容（如HTML文件、.config文件和图像文件）的副本。在不带源代码的情况下进行部署并不会为您的知识产权提供牢不可破的保护，因为聪明的ISP仍然可以通过反编译生成的程序集来弄清楚应用程序的来龙去脉，但是，它确实对一般的代码窃取者设置了更大的阻碍。

新的代码分隔模型

ASP.NET 1.x支持两种编程模型：内联模型—HTML和代码共存于同一个ASPX文件中；代码隐藏模型—它将HTML分隔到ASPX文件中，并将代码分隔到源代码文件（例如，C#文件）中。ASP.NET 2.0引入了第三个模型：一种新的代码隐藏形式，它依赖于Visual C#和Visual Basic .NET编译器中的不完全类支持。新的代码隐藏解决了原来的代码隐藏中存在的一个恼人的问题：传统的代码隐藏类必须包含受保护的字段，这些字段的类型和名称需要映射到ASPX文件中声明的相应控件。

图10 显示了新的代码隐藏模型的工作方式。Hello.aspx包含页面的声明部分，Hello.aspx.cs包含代码。您应该注意@ Page指令中的CompileWith属性。此外，请注意MyPage类中缺少的字段（它们提供到ASPX文件中声明的控件的映射）。旧样式的代码隐藏仍然受支持，但新样式将是今后的首选编程模型。一点都不奇怪，Visual Studio 2005天生就支持新的代码分隔模型。

Hello.aspx

<%@ Page CompileWith="Hello.aspx.cs" ClassName="MyPage" %>

Hello.aspx.cs

using System;

partial class MyPage
{
    void OnTest (Object sender, EventArgs e)
    {
        Output.Text = "Hello, " + Input.Text;
    }
}

图10 Codebehind模型

客户端回调管理器

ASP.NET 2.0中我最喜欢的功能之一就是由新的客户端回调管理器提供的“轻量级回发”功能。在过去，ASP.NET页面必须回发给服务器才能调用服务器端代码。回发是低效的，因为它们将包含由页面控件生成的所有回发数据。它们还强制页面刷新，从而导致不雅观的闪烁。

ASP.NET 2.0引入了客户端回调管理器，它使页面无需完全回发就可以回调到服务器。回调是异步的，并且通过XML-HTTP来完成。它们不包含回发数据，并且不会强制页面刷新。（在服务器端，页面像平常一样执行至PreRender事件，但在即将呈现任何HTML之前停止。）它们确实需要支持XML-HTTP协议的浏览器（这通常意味着Microsoft Internet Explorer 5.0或更高版本）。

使用客户端回调管理器涉及三个步骤。首先，调用Page.GetCallbackEventReference以获取对某个特定函数（可以从客户端脚本中调用该函数，以执行到服务器的XML-HTTP回调）的引用。ASP.NET提供了该函数的名称和实现。其次，在客户端脚本中编写一个将在回调返回时调用的方法。方法名称是传递给GetCallbackEventReference的参数之一。第三，在页面中实现ICallbackEventHandler接口。该接口包含一个方法—RaiseCallbackEvent，当回调发生时，该方法将在服务器端调用。RaiseCallbackEvent所返回的字符串将被返回到第二步所述的方法。

图11 中的代码显示了客户端回调的工作方式，并且演示了它们的一个非常实际的用途。该页面显示了一个请求姓名和地址的窗体。在Zip Code字段中键入378xx或379xx邮政编码，然后单击Autofill按钮，City字段中将显示一个名称。值得注意的是，该页面会返回到服务器以获取城市名称，但它使用客户端回调而不是完全回发来完成此工作。在实际操作中，它可以找到某个数据库以将邮政编码转换为城市名称。请注意，该页面并不像页面在回发到服务器时通常所做的那样进行重新绘制。相反，更新是快速且简洁的！

<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>

<html>
    <body>
        <h1>Please Register</h1>
        <hr>
        <form runat="server">
            <table>
                <tr>
                    <td>First Name</td>
                    <td><asp:TextBox ID="FirstName" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>Last Name</td>
                    <td><asp:TextBox ID="LastName" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>Address 1</td>
                    <td><asp:TextBox ID="Address1" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>Address 2</td>
                    <td><asp:TextBox ID="Address2" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>City</td>
                    <td><asp:TextBox ID="City" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>State</td>
&n,bsp;                  <td><asp:TextBox ID="State" RunAt="server" /></td>
                    <td></td>
                </tr>
                <tr>
                    <td>Zip Code</td>
                    <td><asp:TextBox ID="Zip" RunAt="server" /></td>
                    <td><asp:Button ID="AutofillButton" Text="Autofill"
                        RunAt="server" /></td>
                </tr>
            </table>
        </form>
    </body>
</html>

// Wire the callback event reference to the Autofill button with
    // an onclick attribute (and add "return false" to event reference
    // to prevent a postback from occurring)
    AutofillButton.Attributes.Add ("onclick",
        cbref + "; return false;");
}

// Server-side callback event handler
string ICallbackEventHandler.RaiseCallbackEvent (string arg)
{
    if (arg.StartsWith ("378"))
        return "Oak Ridge";
    else if (arg.StartsWith ("379"))
        return "Knoxville";
    else
        return "Unknown";
}
</script>

转载于:https://www.cnblogs.com/yohen/articles/877407.html