ASP.NET4 与 VS2010 Web 开发页面服务改进

转：http://blog.163.com/kele_lipeng/blog/static/81345278201132754729336/

作者：朱先忠

本文将接着上一篇 ASP.NET4与VS2010Web开发核心服务改进 继续讨论核心ASP.NET服务方面的改进。

四、永久重定向页面

一种常见的Web应用程序做法是，随着时间的推移经常移动网页和其他内容，从而导致搜索引擎失效链接的积累。在ASP.NET中，开发商通常采用的处理旧网址请求的方案是，使用 Response.Redirect方法把对旧网址的请求转发到新网址。然而，当用户尝试访问的旧网址时，使用Redirect方法会导致一个“HTTP 302 Found”(临时重定向)响应，从而相应地产生一次额外的HTTP往返。

ASP.NET 4增加了一个新的RedirectPermanent辅助方法，可以方便地发出“HTTP 301 Moved Permanently”响应，如下面的例子所示：

RedirectPermanent("/newpath/foroldcontent.aspx");

搜索引擎及其他识别永久重定向的用户代理程序都将会存储起与此内容相关的新的网址，从而消除不必要的因临时重定向导致的HTTP往返。

五、极具伸缩性的会话状态管理

ASP.NET针对在Web场中存储会话状态提供了两个默认选项：一个调用进程外会话状态服务器的会话状态提供程序，和一个能够把数据存储在Microsoft SQL Server数据库中的会话状态提供程序。由于这两个选项都牵涉到在Web应用程序的工作进程外存储状态信息，所以，在把会话状态发送到远程存储之前必须把它序列化。根据开发者在会话状态中保存信息的多少，序列化数据的尺寸可能增长到相当大。

ASP.NET 4引入了一个针对两种进程外会话状态提供程序的新的压缩选项。当显示在下面的示例中的compressionEnabled配置选项被设置为true时，ASP.NET将会使用.NET框架的System.IO.Compression.GZipStream类来压缩(和解压)序列化的会话状态。

<sessionState
  mode="SqlServer"
  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

通过把此新的属性简单地添加到Web.config文件中，在Web服务器中具有空闲的CPU周期的应用程序便可以实现大幅度地减小序列化的会话状态数据的大小。

六、扩展URL最大长度

ASP.NET 4引入了新的选择用于扩展应用程序URL的规模。早期版本的ASP.NET把URL路径的长度限制为最长260个字符(基于NTFS文件路径限制)。在ASP.NET 4中，您可以选择增加(或减少)这个数目以便更适合于你的应用程序，这是使用两个新的httpRuntime配置属性实现的。下面的例子显示了这些新的属性的使用。

<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />

为了使用更长或更短的路径(不包括协议、服务器名称和查询字符串的URL中的部分)，你可以修改maxRequestPathLength属性的值。为了使用更长或更短的查询字符串，你可以修改maxQueryStringLength属性的值。

在ASP.NET 4中，您还可以配置由URL字符检查机制所使用的字符。当ASP.NET查找到一个URL路径中的无效字符时，它将拒绝该请求，并发出一个HTTP 400错误。在以前版本的ASP.NET中，URL字符检查仅限于一个固定的字符集。在ASP.NET 4，您可以自定义一个有效的字符集，这可以通过使用HttpRuntime配置元素中新的requestPathInvalidChars属性实现，如下面的示例所示：

<httpRuntime requestPathInvalidChars="<,>,*,%,&,:,\" />

默认情况下，requestPathInvalidChars属性定义7个无效的字符。(默认情况下，在分配给requestPathInvalidChars的字符串中，小于号(“<”)，大于号(“<”)和符号&都被进行编码，因为文件Web.config是一个XML文件。)您可以根据需要自定义设置无效的字符。

【注意】ASP.NET 4始终会拒绝包含在0x00～0x1F范围的ASCII字符的URL路径，因为这些都是IETF的RFC 2396文件中所规定驱动的无效的URL字符。在运行6.0或更高的IIS的Windows 版本中，Http.sys协议设备程序会自动拒绝其中包含这些字符的URL。

七、可扩展请求校验

ASP.NET请求验证机制会搜索传入的HTTP请求数据中的通常用在跨站点脚本(XSS)攻击中的字符串。如果发现存在潜在的XSS字符串，请求验证将会标志出被怀疑的字符串并返回一个错误。内置的请求验证只有当发现最常见的跨站脚本攻击中使用的字符串时才返回一个错误。以前的XSS验证过于积极，从而导致许多的误判。不过，有时候用户的确可能会请求一个具有攻击意味的验证，但也有可能想有意放宽对特定的网页或特定类型请求的跨站脚本检查。

在ASP.NET 4中，对请求验证功能进行了扩展，以便您可以使用自定义的请求验证逻辑。为了扩展请求验证，你可以从新的System.Web.Util.RequestValidator类派生一个类，并配置应用程序(在Web.config文件的httpRuntime节中)以使用你的自定义类型。下面的示例显示了如何配置一个自定义的请求验证类：

<httpRuntime requestValidationType="Samples.MyValidator, Samples" />

注意，这个新的requestValidationType属性要求使用一个标准的.NET Framework类型标识符字符串来指定提供定制请求验证的类。对于每个请求，ASP.NET调用自定义类型来处理每一个传入的HTTP请求数据块。通过下面给出的例子中的自定义的请求验证类，传入的网址、所有的HTTP头部(包括cookie和自定义头部)和整个实体部分都可以被检查：

public class CustomRequestValidation : RequestValidator
{
  protected override bool IsValidRequestString(
      HttpContext context, string value,
      RequestValidationSource requestValidationSource,
      string collectionKey,
      out int validationFailureIndex)
    {...}
}

对于您不希望检查的传入的HTTP数据的情况，请求验证类可以退让给ASP.NET的默认请求验证部分—这是通过简单地调用base.IsValidRequestString实现的。

八、对象缓存和对象缓存扩展

自第一个版本发行以来，ASP.NET提供了一个功能强大的内存对象缓存(System.Web.Caching.Cache)。缓存应用非常受欢迎，即使在非Web应用程序中也被广泛应用。但是，仅为了能够使用ASP.NET对象缓存而在一个Windows窗体或WPF应用程序中包括对于System.Web.dll程序集的引用这真是一件令人尴尬的事情。

为了使所有应用程序都能够利用缓存，.NET Framework 4引入了一个新的程序集，一个新的命名空间，一些基本类型和一个具体的缓存实现。新程序集System.Runtime.Caching.dll中在System.Runtime.Caching命名空间中包含了一个新的缓存API。该命名空间包含了两个核心的类集：

? 为定制缓存实现提供了一些具备基本功能的抽象类型。

? 提供了一个具体的内存对象缓存实现(即System.Runtime.Caching.MemoryCache类)。

新的MemoryCache类的建模方式极类似于ASP.NET缓存，其中使用了相当部分的ASP.NET中的内部缓引擎逻辑。虽然已经更新System.Runtime.Caching中的公共缓存API以支持开发自定义缓存，但是如果您使用ASP.NET Cache对象的话，那么你在使用新的API过程中会发现许多熟悉的概念。

要深入讨论新的MemoryCache类和相应的基本支持API，你需要参考其他更完整的文档。但是，下面的例子让你对新的缓存API的使用方式有一个大致的了解。注意，这个例子是一个Windows窗体应用程序的一部分，其中并没有依赖于System.Web.dll程序集。

private void btnGet_Click(object sender, EventArgs e)
{
  //Obtain a reference to the default MemoryCache instance.
  //Note that you can create multiple MemoryCache(s) inside
  //of a single application.
  ObjectCache cache = MemoryCache.Default;
  //In this example the cache is storing the contents of a file string 
  fileContents = cache["filecontents"] as string;
  //If the file contents are not currently in the cache, then 
  //the contents are read from disk and placed in the cache.
  if (fileContents == null)
  {
    //A CacheItemPolicy object holds all the pieces of cache
    //dependency and cache expiration metadata related to a single 
    //cache entry.
    CacheItemPolicy policy = new CacheItemPolicy();
    //Build up the information necessary to create a file dependency.
    //In this case we just need the file path of the file on disk.
    List<string> filePaths = new List<string>();
    filePaths.Add("c:\\data.txt");
    //In the new cache API, dependencies are called "change monitors".
    //For this example we want the cache entry to be automatically expired
    //if the contents on disk change. A HostFileChangeMonitor provides
    //this functionality.
    policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths));
    //Fetch the file's contents 
    fileContents = File.ReadAllText("c:\\data.txt");
    //And then store the file's contents in the cache 
    cache.Set("filecontents", fileContents, policy);
  }
  MessageBox.Show(fileContents);
}

九、可扩展的HTML、URL和HTTP头部编码

在ASP.NET 4中，您可以针对常见的文本编码任务，例如HTML编码，URL编码、HTML属性编码和输出的HTTP头部编码等，创建自定义编码例程。您可以通过从新的System.Web.Util.HttpEncoder类型中进行派生来创建定制的编码器，然后配置ASP.NET以便在配置文件Web.config的httpRuntime节中使用该定制类型，如下面的示例所示：

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />

配置好自定义编码器后，当调用System.Web.HttpUtility或System.Web.HttpServerUtility类的公共方法时ASP.NET会自动调用此自定义的编码实现。这样一来，可以让Web开发团队的一部分开发定制的字符编码器，而Web开发团队的其他成员继续使用公共的ASP.NET编码API。通过在httpRuntime元素中集中配置自定义编码器，您可以确保从公共的ASP.NET编码API中对所有文本编码的调用都要路由到你的自定义编码器。

十、在单个工作进程中对个体应用程序进行性能监控

为了增加宿主在一台服务器上的网站的数目，许多托管机构都选择在一个工作进程中运行多个ASP.NET应用程序。但是，如果多个应用程序使用一个共享的工作进程，服务器管理员很难确定出现问题的个体应用程序。

如今ASP.NET 4中可以利用新的由CLR推出的资源监测功能。要启用此功能，您可以在Aspnet.config配置文件中添加下面的XML配置片断。

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 
</configuration>

【注意】这个Aspnet.config文件位于NET Framework安装目录下，不同于Web.config文件。

当启用appDomainResourceMonitoring功能后，可以在“ASP.NET应用程序”性能类别中看到有两个新的性能计数器可用：托管处理器时间(Managed Processor Time)和托管使用的内存(Managed Memory Used)。这两个性能计数器都会使用新的CLR应用程序域的资源管理功能来跟踪估计个体ASP.NET应用程序的CPU时间和托管内存利用情况。因此，通过使用ASP.NET 4，管理员现在可以更准确地估计运行于单个工作进程中的个体应用程序消费的资源情况。

十一、多目标平台开发

您可以创建一个运行于特定版本的.NET框架上的应用程序。在ASP.NET 4中，在Web.config文件的compilation元素有一个新属性可以让你的程序的运行平台针对.NET框架4和更高版本。如果你明确你的程序的运行目标是.NET框架4，并且如果您在Web.config文件中包括了一些可选元素，如system.codedom入口等，那么这些元素都必须适合于.NET框架4才行。(如果你没有明确指出你的程序的运行目标，那么系统将通过Web.config文件中的未提供的项进行自行推断。)

下面的例子显示了在Web.config文件的compilation元素的targetFramework属性的使用方式。

<compilation targetFramework="4.0"/>

另外，请注意如下的一些关于配置你的应用程序运行于.NET Framework特定版本方面的描述：

? 在一个.NET Framework 4应用程序池中，如果文件Web.config中不包含targetFramework属性或者如果丢失文件Web.config的话，ASP.NET构建系统总是假定.NET Framework 4为运行目标平台。(为了使你的程序运行于.NET框架4上，你很可能需要对你的代码进行一些修改。)

? 如果你确实包含了targetFramework属性，并且如果在文件Web.config中定义了system.codeDom元素，那么这个文件必须要包含针对.NET框架4的正确的入口。

? 如果你在使用aspnet_compiler命令预编译你的应用程序(例如一个构建环境)，那么你必须使用针对目标框架的正确版本的aspnet_compile命令。你可以使用随同.NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727)一同发布的编译器针对.NET框架3.5或更早的版本进行编译。你还可以使用随同.NET Framework 4一同发布的编译器来编译使用这个新框架及以后更新的框架的应用程序。

? 在运行时，编译器将使用安装在本机上的最新的框架程序集(因此它们都应当位于GAC中)。如果以后对框架进行了更新(例如，假定安装了一个4.1版本)，那么你将能够使用新版本框架中的特性，即使你设置的targetFramework属性是针对一个低版本的框架(例如4.0)。(但是，在VS2010中在设计时或当你使用aspnet_compiler命令时，使用框架的更新的特性将导致编译时错误)。