博客园_Fish Li

细说ASP.NET Windows身份认证

2012-05-07T00:27:00Z

上篇博客我谈到了一些关于ASP.NET Forms身份认证方面的话题，这次的博客将主要介绍ASP.NET Windows身份认证。

Forms身份认证虽然使用广泛，不过，如果是在 Windows Active Directory 的环境中使用ASP.NET，那么使用Windows身份认证也会比较方便。方便性表现为：我们不用再设计登录页面，不用编写登录验证逻辑。而且使用Windows身份认证会有更好的安全保障。

认识ASP.NET Windows身份认证

要使用Windows身份认证模式，需要在web.config设置：

Windows身份认证做为ASP.NET的默认认证方式，与Forms身份认证在许多基础方面是一样的。上篇博客我说过：我认为ASP.NET的身份认证的最核心部分其实就是HttpContext.User这个属性所指向的对象。在接下来的部分，我将着重分析这个对象在二种身份认证中有什么差别。

在ASP.NET身份认证过程中，IPrincipal和IIdentity这二个接口有着非常重要的作用。前者定义用户对象的基本功能，后者定义标识对象的基本功能，不同的身份认证方式得到的这二个接口的实例也是不同的。

ASP.NET Windows身份认证是由WindowsAuthenticationModule实现的。WindowsAuthenticationModule在ASP.NET管线的AuthenticateRequest事件中，使用从IIS传递到ASP.NET的Windows访问令牌(Token)创建一个WindowsIdentity对象，Token通过调用context.WorkerRequest.GetUserToken()获得，然后再根据WindowsIdentity 对象创建WindowsPrincipal对象，然后把它赋值给HttpContext.User。

在Forms身份认证中，我们需要创建登录页面，让用户提交用户名和密码，然后检查用户名和密码的正确性，接下来创建一个包含FormsAuthenticationTicket对象的登录Cookie供后续请求使用。FormsAuthenticationModule在ASP.NET管线的AuthenticateRequest事件中，解析登录Cookie并创建一个包含FormsIdentity的GenericPrincipal对象，然后把它赋值给HttpContext.User。

上面二段话简单了概括了二种身份认证方式的工作方式。
我们可以发现它们存在以下差别：
1. Forms身份认证需要Cookie表示登录状态，Windows身份认证则依赖于IIS
2. Windows身份认证不需要我们设计登录页面，不用编写登录验证逻辑，因此更容易使用。

在授权阶段，UrlAuthorizationModule仍然会根据当前用户检查将要访问的资源是否得到许可。接下来，FileAuthorizationModule检查 HttpContext.User.Identity 属性中的 IIdentity 对象是否是 WindowsIdentity 类的一个实例。如果 IIdentity 对象不是 WindowsIdentity 类的一个实例，则 FileAuthorizationModule 类停止处理。如果存在 WindowsIdentity 类的一个实例，则 FileAuthorizationModule 类调用 AccessCheck Win32 函数（通过 P/Invoke）来确定是否授权经过身份验证的客户端访问请求的文件。如果该文件的安全描述符的随机访问控制列表 (DACL) 中至少包含一个 Read 访问控制项 (ACE)，则允许该请求继续。否则，FileAuthorizationModule 类调用 HttpApplication.CompleteRequest 方法并将状态码 401 返回到客户端。

在Windows身份认证中，验证工作主要是由IIS实现的，WindowsAuthenticationModule其实只是负责创建WindowsPrincipal和WindowsIdentity而已。顺便介绍一下：Windows 身份验证又分为“NTLM 身份验证”和“Kerberos v5 身份验证”二种，关于这二种Windows身份认证的更多说明可查看MSDN技术文章：解释：ASP.NET 2.0 中的 Windows 身份验证。在我看来，IIS最终使用哪种Windows身份认证方式并不影响我们的开发过程，因此本文不会讨论这个话题。

根据我的实际经验来看，使用Windows身份认证时，主要的开发工作将是根据登录名从Active Directory获取用户信息。因为，此时不需要我们再设计登录过程，IIS与ASP.NET已经为我们准备好了WindowsPrincipal和WindowsIdentity这二个与用户身份相关的对象。

访问 Active Directory

我们通常使用LDAP协议来访问Active Directory，在.net framework中提供了DirectoryEntry和DirectorySearcher这二个类型让我们可以方便地从托管代码中访问 Active Directory 域服务。

如果我们要在"test.corp”这个域中搜索某个用户信息，我们可以使用下面的语句构造一个DirectoryEntry对象：

DirectoryEntry entry = new DirectoryEntry("LDAP://test.corp");

在这段代码中，我采用硬编码的方式把域名写进了代码。
我们如何知道当前电脑所使用的是哪个域名呢？
答案是：查看“我的电脑”的属性对话框：

注意：这个域名不一定与System.Environment.UserDomainName相同。

除了可以查看“我的电脑”的属性对话框外，我们还可以使用代码的方式获取当前电脑所使用的域名：

private static string GetDomainName()
{
// 注意：这段代码需要在Windows XP及较新版本的操作系统中才能正常运行。
SelectQuery query = new SelectQuery("Win32_ComputerSystem");
using( ManagementObjectSearcher searcher = new ManagementObjectSearcher(query) ) {
foreach( ManagementObject mo in searcher.Get() ) {
if( (bool)mo["partofdomain"] )
return mo["domain"].ToString();
}
}
return null;
}

当构造了DirectorySearcher对象后，我们便可以使用DirectorySearcher来执行对Active Directory的搜索。
我们可以使用下面的步骤来执行搜索：
1. 设置 DirectorySearcher.Filter 指示LDAP格式筛选器，这是一个字符串。
2. 多次调用PropertiesToLoad.Add() 设置搜索过程中要检索的属性列表。
3. 调用FindOne() 方法获取搜索结果。

下面的代码演示了如何从Active Directory中搜索登录名为“fl45”的用户信息：

static void Main(string[] args)
{
Console.WriteLine(Environment.UserDomainName);
Console.WriteLine(Environment.UserName);
Console.WriteLine("------------------------------------------------");

ShowUserInfo("fl45", GetDomainName());
}

private static string AllProperties = "name,givenName,samaccountname,mail";

public static void ShowUserInfo(string loginName, string domainName)
{
if( string.IsNullOrEmpty(loginName) || string.IsNullOrEmpty(domainName) )
return;

string[] properties = AllProperties.Split(new char[] { '\r', '\n', ',' },
StringSplitOptions.RemoveEmptyEntries);

try {
DirectoryEntry entry = new DirectoryEntry("LDAP://" + domainName);
DirectorySearcher search = new DirectorySearcher(entry);
search.Filter = "(samaccountname=" + loginName + ")";

foreach( string p in properties )
search.PropertiesToLoad.Add(p);

SearchResult result = search.FindOne();

if( result != null ) {
foreach( string p in properties ) {
ResultPropertyValueCollection collection = result.Properties[p];
for( int i = 0; i < collection.Count; i++ )
Console.WriteLine(p + ": " + collection[i]);
}
}
}
catch( Exception ex ) {
Console.WriteLine(ex.ToString());
}
}

结果如下：

在前面的代码，我在搜索Active Directory时，只搜索了"name,givenName,samaccountname,mail"这4个属性。然而，LDAP还支持更多的属性，我们可以使用下面的代码查看更多的用户信息：

private static string AllProperties = @"
homemdb
distinguishedname
countrycode
cn
lastlogoff
mailnickname
dscorepropagationdata
msexchhomeservername
msexchmailboxsecuritydescriptor
msexchalobjectversion
usncreated
objectguid
whenchanged
memberof
msexchuseraccountcontrol
accountexpires
displayname
primarygroupid
badpwdcount
objectclass
instancetype
objectcategory
samaccounttype
whencreated
lastlogon
useraccountcontrol
physicaldeliveryofficename
samaccountname
usercertificate
givenname
mail
userparameters
adspath
homemta
msexchmailboxguid
pwdlastset
logoncount
codepage
name
usnchanged
legacyexchangedn
proxyaddresses
department
userprincipalname
badpasswordtime
objectsid
sn
mdbusedefaults
telephonenumber
showinaddressbook
msexchpoliciesincluded
textencodedoraddress
lastlogontimestamp
company
";

在ASP.NET中访问Active Directory

前面我在一个控制台程序中演示了访问Active Directory的方法，通过示例我们可以看到：在代码中，我用Environment.UserName就可以得到当前用户的登录名。然而，如果是在ASP.NET程序中，访问Environment.UserName就很有可能得不到真正用户登录名。因为：Environment.UserName是使用WIN32API中的GetUserName获取线程相关的用户名，但ASP.NET运行在IIS中，线程相关的用户名就不一定是客户端的用户名了。不过，ASP.NET可以模拟用户方式运行，通过这种方式才可以得到正确的结果。关于“模拟”的话题在本文的后面部分有说明。

在ASP.NET中，为了能可靠的获取登录用户的登录名，我们可以使用下面的代码：

/// <summary>
/// 根据指定的HttpContext对象，获取登录名。
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
public static string GetUserLoginName(HttpContext context)
{
if( context == null )
return null;

if( context.Request.IsAuthenticated == false )
return null;

string userName = context.User.Identity.Name;
// 此时userName的格式为：UserDomainName\LoginName
// 我们只需要后面的LoginName就可以了。

string[] array = userName.Split(new char[] { '\\' }, StringSplitOptions.RemoveEmptyEntries);
if( array.Length == 2 )
return array[1];

return null;
}

在ASP.NET中使用Windows身份认证时，IIS和WindowsAuthenticationModule已经做了许多验证用户的相关工作，虽然我们可以使用前面的代码获取到用户的登录名，但用户的其它信息即需要我们自己来获取。在实际使用Windows身份认证时，我们要做的事：基本上就是从Active Directory中根据用户的登录名获取所需的各种信息。

比如：我的程序在运行时，还需要使用以下与用户相关的信息：

public sealed class UserInfo
{
public string GivenName;
public string FullName;
public string Email;
}

那么，我们可以使用这样的代码来获取所需的用户信息：

public static class UserHelper
{
/// <summary>
/// 活动目录中的搜索路径，也可根据实际情况来修改这个值。
/// </summary>
public static string DirectoryPath = "LDAP://" + GetDomainName();

/// <summary>
/// 获取与指定HttpContext相关的用户信息
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
public static UserInfo GetCurrentUserInfo(HttpContext context)
{
string loginName = GetUserLoginName(context);
if( string.IsNullOrEmpty(loginName) )
return null;

return GetUserInfoByLoginName(loginName);
}

/// <summary>
/// 根据指定的HttpContext对象，获取登录名。
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
public static string GetUserLoginName(HttpContext context)
{
if( context == null )
return null;

if( context.Request.IsAuthenticated == false )
return null;

string userName = context.User.Identity.Name;
// 此时userName的格式为：UserDomainName\LoginName
// 我们只需要后面的LoginName就可以了。

string[] array = userName.Split(new char[] { '\\' }, StringSplitOptions.RemoveEmptyEntries);
if( array.Length == 2 )
return array[1];

return null;
}

/// <summary>
/// 根据登录名查询活动目录，获取用户信息。
/// </summary>
/// <param name="loginName"></param>
/// <returns></returns>
public static UserInfo GetUserInfoByLoginName(string loginName)
{
if( string.IsNullOrEmpty(loginName) )
return null;

// 下面的代码将根据登录名查询用户在AD中的信息。
// 为了提高性能，可以在此处增加一个缓存容器(Dictionary or Hashtable)。

try {
DirectoryEntry entry = new DirectoryEntry(DirectoryPath);
DirectorySearcher search = new DirectorySearcher(entry);
search.Filter = "(SAMAccountName=" + loginName + ")";

search.PropertiesToLoad.Add("givenName");
search.PropertiesToLoad.Add("cn");
search.PropertiesToLoad.Add("mail");
// 如果还需要从AD中获取其它的用户信息，请参考ActiveDirectoryDEMO

SearchResult result = search.FindOne();

if( result != null ) {
UserInfo info = new UserInfo();
info.GivenName = result.Properties["givenName"][0].ToString();
info.FullName = result.Properties["cn"][0].ToString();
info.Email = result.Properties["mail"][0].ToString();
return info;
}
}
catch {
// 如果需要记录异常，请在此处添加代码。
}
return null;
}

private static string GetDomainName()
{
// 注意：这段代码需要在Windows XP及较新版本的操作系统中才能正常运行。
SelectQuery query = new SelectQuery("Win32_ComputerSystem");
using( ManagementObjectSearcher searcher = new ManagementObjectSearcher(query) ) {
foreach( ManagementObject mo in searcher.Get() ) {
if( (bool)mo["partofdomain"] )
return mo["domain"].ToString();
}
}
return null;
}

}

使用UserHelper的页面代码：

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>WindowsAuthentication DEMO - http://www.cnblogs.com/fish-li/</title>
</head>
<body>
<% if( Request.IsAuthenticated ) { %>
当前登录全名：<%= Context.User.Identity.Name.HtmlEncode()%> <br />

<% var user = UserHelper.GetCurrentUserInfo(Context); %>
<% if( user != null ) { %>
用户短名：<%= user.GivenName.HtmlEncode()%> <br />
用户全名：<%= user.FullName.HtmlEncode() %> <br />
邮箱地址：<%= user.Email.HtmlEncode() %>
<% } %>
<% } else { %>
当前用户还未登录。
<% } %>
</body>
</html>

程序运行的效果如下：

另外，还可以从Active Directory查询一个叫做memberof的属性（它与Windows用户组无关），有时候可以用它区分用户，设计与权限相关的操作。

在设计数据持久化的表结构时，由于此时没有“用户表”，那么我们可以直接保存用户的登录名。剩下的开发工作就与Forms身份认证没有太多的差别了。

使用Active Directory验证用户身份

前面介绍了ASP.NET Windows身份认证，在这种方式下，IIS和WindowsAuthenticationModule为我们实现了用户身份认证的过程。然而，有时可能由于各种原因，需要我们以编程的方式使用Active Directory验证用户身份，比如：在WinForm程序，或者其它的验证逻辑。

我们不仅可以从Active Directory中查询用户信息，也可以用它来实现验证用户身份，这样便可以实现自己的登录验证逻辑。

不管是如何使用Active Directory，我们都需要使用DirectoryEntry和DirectorySearcher这二个对象。DirectoryEntry还提供一个构造函数可让我们输入用户名和密码：

// 摘要:
// 初始化 System.DirectoryServices.DirectoryEntry 类的新实例。
//
// 参数:
// Password:
// 在对客户端进行身份验证时使用的密码。DirectoryEntry.Password 属性初始化为该值。
//
// username:
// 在对客户端进行身份验证时使用的用户名。DirectoryEntry.Username 属性初始化为该值。
//
// Path:
// 此 DirectoryEntry 的路径。DirectoryEntry.Path 属性初始化为该值。
public DirectoryEntry(string path, string username, string password);

要实现自己的登录检查，就需要使用这个构造函数。
以下是我写用WinForm写的一个登录检查的示例：

private void btnLogin_Click(object sender, EventArgs e)
{
if( txtUsername.Text.Length == 0 || txtPassword.Text.Length == 0 ) {
MessageBox.Show("用户名或者密码不能为空。", this.Text, MessageBoxButtons.OK, MessageBoxIcon.Warning);
return;
}

string ldapPath = "LDAP://" + GetDomainName();
string domainAndUsername = Environment.UserDomainName + "\\" + txtUsername.Text;
DirectoryEntry entry = new DirectoryEntry(ldapPath, domainAndUsername, txtPassword.Text);

DirectorySearcher search = new DirectorySearcher(entry);

try {
SearchResult result = search.FindOne();

MessageBox.Show("登录成功。", this.Text, MessageBoxButtons.OK, MessageBoxIcon.Information);
}
catch( Exception ex ) {
// 如果用户名或者密码不正确，也会抛出异常。
MessageBox.Show(ex.Message, this.Text, MessageBoxButtons.OK, MessageBoxIcon.Stop);
}
}

程序运行的效果如下：

安全上下文与用户模拟

在ASP.NET Windows身份认证环境中，与用户相关的安全上下文对象保存在HttpContext.User属性中，是一个类型为WindowsPrincipal的对象，我们还可以访问HttpContext.User.Identity来获取经过身份认证的用户标识，它是一个WindowsIdentity类型的对象。

在.NET Framework中，我们可以通过WindowsIdentity.GetCurrent()获取与当前线程相关的WindowsIdentity对象，这种方法获取的是当前运行的Win32线程的安全上下文标识。由于ASP.NET运行在IIS进程中，因此ASP.NET线程的安全标识其实是从IIS的进程中继承的，所以此时用二种方法得到的WindowsIdentity对象其实是不同的。

在Windows操作系统中，许多权限检查都是基于Win32线程的安全上下文标识，于是前面所说的二种WindowsIdentity对象会造成编程模型的不一致问题，为了解决这个问题，ASP.NET提供了“模拟”功能，允许线程以特定的Windows帐户的安全上下文来访问资源。

为了能更好的理解模拟的功能，我准备了一个示例（ShowWindowsIdentity.ashx）：

public class ShowWindowsIdentity : IHttpHandler {

public void ProcessRequest (HttpContext context) {
// 要观察【模拟】的影响，
// 可以启用，禁止web.config中的设置：<identity impersonate="true"/>

context.Response.ContentType = "text/plain";

context.Response.Write(Environment.UserDomainName + "\\" + Environment.UserName + "\r\n");

WindowsPrincipal winPrincipal = (WindowsPrincipal)HttpContext.Current.User;
context.Response.Write(string.Format("HttpContext.Current.User.Identity: {0}, {1}\r\n",
winPrincipal.Identity.AuthenticationType, winPrincipal.Identity.Name));

WindowsPrincipal winPrincipal2 = (WindowsPrincipal)Thread.CurrentPrincipal;
context.Response.Write(string.Format("Thread.CurrentPrincipal.Identity: {0}, {1}\r\n",
winPrincipal2.Identity.AuthenticationType, winPrincipal2.Identity.Name));

WindowsIdentity winId = WindowsIdentity.GetCurrent();
context.Response.Write(string.Format("WindowsIdentity.GetCurrent(): {0}, {1}",
winId.AuthenticationType, winId.Name));
}

首先，在web.config中设置:

注意：要把网站部署在IIS中，否则看不出效果。

此时，访问ShowWindowsIdentity.ashx，将看到如下图所示的结果：

现在修改一下web.config中设置：（注意：后面加了一句配置）

此时，访问ShowWindowsIdentity.ashx，将看到如下图所示的结果：

说明：
1. FISH-SRV2003是我的计算机名。它在一个没有域的环境中。
2. fish-li是我的一个Windows帐号的登录名。
3. 网站部署在IIS6中，进程以NETWORK SERVICE帐号运行。
4. 打开网页时，我输入的用户名是fish-li

前面二张图片的差异之处其实也就是ASP.NET的“模拟”所发挥的功能。

关于模拟，我想说四点：
1. 在ASP.NET中，我们应该访问HttpContext.User.Identity获取当前用户标识，那么就不存在问题（此时可以不需要模拟），例如FileAuthorizationModule就是这样处理的。
2. 模拟只是在ASP.NET应用程序访问Windows系统资源时需要应用Windows的安全检查功能才会有用。
3. Forms身份认证也能配置模拟功能，但只能模拟一个Windows帐户。
4. 绝大多数情况下是不需要模拟的。

在IIS中配置Windows身份认证

与使用Forms身份认证的程序不同，使用Windows身份认证的程序需要额外的配置步骤。这个小节将主要介绍在IIS中配置Windows身份认证，我将常用的IIS6和IIS7.5为例分别介绍这些配置。

IIS6的配置 请参考下图：

IIS7.5的配置 请参考下图：

注意：Windows身份认证是需要安装的，方法请参考下图：

关于浏览器的登录对话框问题

当我们用浏览器访问一个使用Windows身份认证的网站时，浏览器都会弹出一个对话框（左IE，右Safari）：

此时，要求我们输入Windows的登录帐号，然后交给IIS验证身份。

首次弹出这个对话框很正常：因为程序要验证用户的身份。
然而，每次关闭浏览器下次重新打开页面时，又会出现此对话框，此时感觉就很不方便了。
虽然有些浏览器能记住用户名和密码，但我发现FireFox，Opera，Chrome仍然会弹出这个对话框，等待我们点击确定，只有Safari才不会打扰用户直接打开网页。IE的那个“记住我的密码”复选框完全是个摆设，它根本不会记住密码！

因此，我所试过的所有浏览器中，只有Safari是最人性化的。
虽然在默认情况下，虽然IE不会记住密码，每次都需要再次输入。
不过，IE却可以支持不提示用户输入登录帐号而直接打开网页，此时IE将使用用户的当前Windows登录帐号传递给IIS验证身份。

要让IE打开一个Windows身份认证的网站不提示登录对话框，必须满足以下条件：
1. 必须在 IIS 的 Web 站点属性中启用 Windows 集成身份验证。
2. 客户端和Web服务器都必须在基于Microsoft Windows的同一个域内。
3. Internet Explorer 必须把所请求的 URL 视为 Intranet（本地）。
4. Internet Explorer 的 Intranet 区域的安全性设置必须设为“只在 Intranet 区域自动登录”。
5. 请求Web页的用户必须具有访问该Web页以及该Web页中引用的所有对象的适当的文件系统(NTFS)权限。
6. 用户必须用域帐号登录到Windows 。

在这几个条件中，如果网站是在一个Windows域中运行，除了第3条可能不满足外，其它条件应该都容易满足（第4条是默认值）。因此，要让IE不提示输入登录帐号，只要确保第3条满足就可以了。下面的图片演示了如何完成这个配置：（注意：配置方法也适合用域名访问的情况）

另外，除了在IE中设置Intranet外，还可以在访问网站时，用计算机名代替IP地址或者域名，那么IE始终认为是在访问Intranet内的网站，此时也不会弹出登录对话框。

在此，我想再啰嗦三句：
1. IE在集成Windows身份认证时，虽然不提示登录对话框，但是不表示不安全，它会自动传递登录凭据。
2. 这种行为只有IE才能支持。（其它的浏览器只是会记住密码，在实现上其实是不一样的。）
3. 集成Windows身份认证，也只适合在Intranet的环境中使用。

在客户端代码中访问Windows身份认证的页面

在上篇博客中，我演示了如何用代码访问一个使用Forms身份认证的网站中的受限页面，方法是使用CookieContainer对象接收服务端生的登录Cookie。然而，在Windows身份认证的网站中，身份验证的过程发生在IIS中，而且根本不使用Cookie保存登录状态，而是需要在请求时发送必要的身份验证信息。

在使用代码做为客户端访问Web服务器时，我们仍然需要使用HttpWebRequest对象。为了能让HttpWebRequest在访问IIS时发送必要的身份验证信息，HttpWebRequest提供二个属性都可以完成这个功能：

// 获取或设置请求的身份验证信息。
//
// 返回结果:
// 包含与该请求关联的身份验证凭据的 System.Net.ICredentials。默认为 null。
public override ICredentials Credentials { get; set; }

// 获取或设置一个 System.Boolean 值，该值控制默认凭据是否随请求一起发送。
//
// 返回结果:
// 如果使用默认凭据，则为 true；否则为 false。默认值为 false。
public override bool UseDefaultCredentials { get; set; }

下面是我准备的完整的示例代码（注意代码中的注释）：

static void Main(string[] args)
{
try {
// 请把WindowsAuthWebSite1这个网站部署在IIS中，
// 开启Windows认证方式，并禁止匿名用户访问。
// 然后修改下面的访问地址。
HttpWebRequest request =
(HttpWebRequest)WebRequest.Create("http://localhost:33445/Default.aspx");

// 下面三行代码，启用任意一行都是可以的。
request.UseDefaultCredentials = true;
//request.Credentials = CredentialCache.DefaultCredentials;
//request.Credentials = CredentialCache.DefaultNetworkCredentials;
// 如果上面的三行代码全被注释了，那么将会看到401的异常信息。

using( HttpWebResponse response = (HttpWebResponse)request.GetResponse() ) {
using( StreamReader sr = new StreamReader(response.GetResponseStream()) ) {
Console.WriteLine(sr.ReadToEnd());
}
}
}
catch( WebException wex ) {
Console.WriteLine("=====================================");
Console.WriteLine("异常发生了。");
Console.WriteLine("=====================================");
Console.WriteLine(wex.Message);
}
}

其实关键部分还是设置UseDefaultCredentials或者Credentials，代码中的三种方法是有效的。
这三种方法的差别：
1. Credentials = CredentialCache.DefaultCredentials; 表示在发送请求会带上当前用户的身份验证凭据。
2. UseDefaultCredentials = true; 此方法在内部会调用前面的方法，因此与前面的方法是一样的。
3. Credentials = CredentialCache.DefaultNetworkCredentials; 是在.NET 2.0中引用的新方法。

关于DefaultCredentials和DefaultNetworkCredentials的更多差别，请看我整理的表格：

Credentials属性	申明类型	实例类型	.NET支持版本
DefaultCredentials	ICredentials	SystemNetworkCredential	从1.0开始
DefaultNetworkCredentials	NetworkCredential	SystemNetworkCredential	从2.0开始

三个类型的继承关系：
1. NetworkCredential实现了ICredentials接口，
2. SystemNetworkCredential继承自NetworkCredential。

在结束这篇博客之前，我想我应该感谢新蛋。
在新蛋的网络环境中，让我学会了使用Windows身份认证。
除了感谢之外，我现在还特别怀念 fl45 这个登录名......

点击此处下载示例代码

如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Fish Li】。
因为，我的写作热情也离不开您的肯定支持。

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

细说ASP.NET Forms身份认证

2012-04-15T11:59:00Z

用户登录是个很常见的业务需求，在ASP.NET中，这个过程被称为身份认证。由于很常见，因此，我认为把这块内容整理出来，与大家分享应该是件有意义的事。

在开发ASP.NET项目中，我们最常用的是Forms认证，也叫【表单认证】。这种认证方式既可以用于局域网环境，也可用于互联网环境，因此，它有着非常广泛的使用。这篇博客主要讨论的话题是：ASP.NET Forms 身份认证。

有一点我要申明一下：在这篇博客中，不会涉及ASP.NET的登录系列控件以及membership的相关话题，我只想用比较原始的方式来说明在ASP.NET中是如何实现身份认证的过程。

ASP.NET身份认证基础

在开始今天的博客之前，我想有二个最基础的问题首先要明确：
1. 如何判断当前请求是一个已登录用户发起的？
2. 如何获取当前登录用户的登录名？

在标准的ASP.NET身份认证方式中，上面二个问题的答案是：
1. 如果Request.IsAuthenticated为true，则表示是一个已登录用户。
2. 如果是一个已登录用户，访问HttpContext.User.Identity.Name可获取登录名（都是实例属性）。

接下来，本文将会围绕上面二个问题展开，请继续阅读。

ASP.NET身份认证过程

在ASP.NET中，整个身份认证的过程其实可分为二个阶段：认证与授权。
1. 认证阶段：识别当前请求的用户是不是一个可识别（的已登录）用户。
2. 授权阶段：是否允许当前请求访问指定的资源。

这二个阶段在ASP.NET管线中用AuthenticateRequest和AuthorizeRequest事件来表示。
在认证阶段，ASP.NET会检查当前请求，根据web.config设置的认证方式，尝试构造HttpContext.User对象供我们在后续的处理中使用。在授权阶段，会检查当前请求所访问的资源是否允许访问，因为有些受保护的页面资源可能要求特定的用户或者用户组才能访问。所以，即使是一个已登录用户，也有可能会不能访问某些页面。当发现用户不能访问某个页面资源时，ASP.NET会将请求重定向到登录页面。

受保护的页面与登录页面我们都可以在web.config中指定，具体方法可参考后文。

在ASP.NET中，Forms认证是由FormsAuthenticationModule实现的，URL的授权检查是由UrlAuthorizationModule实现的。

如何实现登录与注销

前面我介绍了可以使用Request.IsAuthenticated来判断当前用户是不是一个已登录用户，那么这一过程又是如何实现的呢？

为了回答这个问题，我准备了一个简单的示例页面，代码如下：

<fieldset><legend>用户状态</legend><form action="<%= Request.RawUrl %>" method="post">
<% if( Request.IsAuthenticated ) { %>
当前用户已登录，登录名：<%= Context.User.Identity.Name.HtmlEncode() %> <br />
<input type="submit" name="Logon" value="退出" />
<% } else { %>
<b>当前用户还未登录。</b>
<% } %>
</form></fieldset>

页面显示效果如下：

根据前面的代码，我想现在能看到这个页面显示也是正确的，是的，我目前还没有登录（根本还没有实现这个功能）。

下面我再加点代码来实现用户登录。页面代码：

<fieldset><legend>普通登录</legend><form action="<%= Request.RawUrl %>" method="post">
登录名：<input type="text" name="loginName" style="width: 200px" value="Fish" />
<input type="submit" name="NormalLogin" value="登录" />
</form></fieldset>

现在页面的显示效果：

登录与退出登录的实现代码：

public void Logon()
{
FormsAuthentication.SignOut();
}

public void NormalLogin()
{
// -----------------------------------------------------------------
// 注意：演示代码为了简单，这里不检查用户名与密码是否正确。
// -----------------------------------------------------------------

string loginName = Request.Form["loginName"];
if( string.IsNullOrEmpty(loginName) )
return;

FormsAuthentication.SetAuthCookie(loginName, true);

TryRedirect();
}

现在，我可试一下登录功能。点击登录按钮后，页面的显示效果如下：

从图片的显示可以看出，我前面写的NormalLogin()方法确实可以实现用户登录。
当然了，我也可以在此时点击退出按钮，那么就回到了图片２的显示。

写到这里，我想有必要再来总结一下在ASP.NET中实现登录与注销的方法：
1. 登录：调用FormsAuthentication.SetAuthCookie()方法，传递一个登录名即可。
2. 注销：调用FormsAuthentication.SignOut()方法。

保护受限制的页面

在一个ASP.NET网站中，有些页面会允许所有用户访问，包括一些未登录用户，但有些页面则必须是已登录用户才能访问，还有一些页面可能会要求特定的用户或者用户组的成员才能访问。这类页面因此也可称为【受限页面】，它们一般代表着比较重要的页面，包含一些重要的操作或功能。

为了保护受限制的页面的访问，ASP.NET提供了一种简单的方式：可以在web.config中指定受限资源允许哪些用户或者用户组（角色）的访问，也可以设置为禁止访问。

比如，网站有一个页面：MyInfo.aspx，它要求访问这个页面的访问者必须是一个已登录用户，那么可以在web.config中这样配置：

为了方便，我可能会将一些管理相关的多个页面放在Admin目录中，显然这些页面只允许Admin用户组的成员才可以访问。对于这种情况，我们可以直接针对一个目录设置访问规则：

这样就不必一个一个页面单独设置了，还可以在目录中创建一个web.config来指定目录的访问规则，请参考后面的示例。

在前面的示例中，有一点要特别注意的是：
1. allow和deny之间的顺序一定不能写错了，UrlAuthorizationModule将按这个顺序依次判断。
2. 如果某个资源只允许某类用户访问，那么最后的一条规则一定是 <deny users="*" />

在allow和deny的配置中，我们可以在一条规则中指定多个用户：
1. 使用users属性，值为逗号分隔的用户名列表。
2. 使用roles属性，值为逗号分隔的角色列表。
3. 问号 (?) 表示匿名用户。
4. 星号 (*) 表示所有用户。

登录页不能正常显示的问题

有时候，我们可能要开发一个内部使用的网站程序，这类网站程序要求 禁止匿名用户的访问，即：所有使用者必须先登录才能访问。因此，我们通常会在网站根目录下的web.config中这样设置：

对于我们的示例，我们也可以这样设置。此时在浏览器打开页面时，呈现效果如下：

从图片中可以看出：页面的样式显示不正确，最下边还多出了一行文字。

这个页面的完整代码是这样的（它引用了一个CSS文件和一个JS文件）：

<%@ Page Language="C#" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FormsAuthentication DEMO - http://www.cnblogs.com/fish-li/</title>
<link type="text/css" rel="Stylesheet" href="css/StyleSheet.css" />
</head>
<body>
<fieldset><legend>普通登录</legend><form action="<%= Request.RawUrl %>" method="post">
登录名：<input type="text" name="loginName" style="width: 200px" value="Fish" />
<input type="submit" name="NormalLogin" value="登录" />
</form></fieldset>

<fieldset><legend>用户状态</legend><form action="<%= Request.RawUrl %>" method="post">
<% if( Request.IsAuthenticated ) { %>
当前用户已登录，登录名：<%= Context.User.Identity.Name.HtmlEncode() %> <br />

<% var user = Context.User as MyFormsPrincipal<UserInfo>; %>
<% if( user != null ) { %>
<%= user.UserData.ToString().HtmlEncode() %>
<% } %>

<input type="submit" name="Logon" value="退出" />
<% } else { %>
<b>当前用户还未登录。</b>
<% } %>
</form></fieldset>

<p id="hideText"><i>不应该显示的文字</i></p>
<script type="text/javascript" src="js/JScript.js"></script>
</body>
</html>

页面最后一行文字平时不显示是因为JScript.js中有以下代码：

document.getElementById("hideText").setAttribute("style", "display: none");

这段JS代码能做什么，我想就不用再解释了。
虽然这段JS代码没什么价值，但我主要是想演示在登录页面中引用JS的场景。

根据前面图片，我们可以猜测到：应该是CSS和JS文件没有正确加载造成的。
为了确认就是这样原因，我们可以打开FireBug再来看一下页面加载情况：

根据FireBug提供的线索我们可以分析出，页面在访问CSS, JS文件时，其实是被重定向到登录页面了，因此获得的结果肯定也是无意义的，所以就造成了登录页的显示不正确。

还记得前所说的【授权】吗？
是的，现在就是由于我们在web.config中设置了不允许匿名用户访问，因此，所有的资源也就不允许匿名用户访问了，包括登录页所引用的CSS, JS文件。当授权检查失败时，请求会被重定向到登录页面，所以，登录页本身所引用的CSS, JS文件最后得到的响应内容其实是登录页的HTML代码，最终导致它们不能发挥作用，表现为登录页的样式显示不正确，以及引用的JS文件也不起作用。

不过，有一点比较奇怪：为什么访问登录页面时，没有发生重定向呢？
原因是这样的：在ASP.NET内部，当发现是在访问登录面时，会设置HttpContext.SkipAuthorization = true （其实是一个内部调用），这样的设置会告诉后面的授权检查模块：跳过这次请求的授权检查。因此，登录页总是允许所有用户访问，但是CSS文件以及JS文件是在另外的请求中发生的，那些请求并不会要跳过授权模块的检查。

为了解决登录页不能正确显示的问题，我们可以这样处理：
1. 在网站根目录中的web.config中设置登录页所引用的JS, CSS文件都允许匿名访问。
2. 也可以直接针对JS, CSS目录设置为允许匿名用户访问。
3. 还可以在CSS, JS目录中创建一个web.config文件来配置对应目录的授权规则。可参考以下web.config文件：

<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</configuration>

第三种做法可以不修改网站根目录下的web.config文件。

注意：在IIS中看到的情况就和在Visual Studio中看到的结果就不一样了。因为，像js, css, image这类文件属于静态资源文件，IIS能直接处理，不需要交给ASP.NET来响应，因此就不会发生授权检查失败，所以，如果这类网站部署在IIS中，看到的结果又是正常的。

认识Forms身份认证

前面我演示了如何用代码实现登录与注销的过程，下面再来看一下登录时，ASP.NET到底做了些什么事情，它是如何知道当前请求是一个已登录用户的？

在继续探索这个问题前，我想有必要来了解一下HTTP协议的一些特点。
HTTP是一个无状态的协议，无状态的意思可以理解为：WEB服务器在处理所有传入请求时，根本就不知道某个请求是否是一个用户的第一次请求与后续请求，或者是另一个用户的请求。WEB服务器每次在处理请求时，都会按照用户所访问的资源所对应的处理代码，从头到尾执行一遍，然后输出响应内容，WEB服务器根本不会记住已处理了哪些用户的请求，因此，我们通常说HTTP协议是无状态的。

虽然HTTP协议与WEB服务器是无状态，但我们的业务需求却要求有状态，典型的就是用户登录，在这种业务需求中，要求WEB服务器端能区分某个请求是不是一个已登录用户发起的，或者当前请求是哪个用户发出的。在开发WEB应用程序时，我们通常会使用Cookie来保存一些简单的数据供服务端维持必要的状态。既然这是个通常的做法，那我们现在就来看一下现在页面的Cookie使用情况吧，以下是我用FireFox所看到的Cookie列表：

这个名字：LoginCookieName，是我在web.config中指定的：

在这段配置中，我不仅指定的登录状态的Cookie名，还指定了身份验证模式，以及Cookie的使用方式。

为了判断这个Cookie是否与登录状态有关，我们可以在浏览器提供的界面删除它，然后刷新页面，此时页面的显示效果如下：

此时，页面显示当前用户没有登录。

为了确认这个Cookie与登录状态有关，我们可以重新登录，然后再退出登录。
发现只要是页面显示当前用户未登录时，这个Cookie就不会存在。

事实上，通过SetAuthCookie这个方法名，我们也可以猜得出这个操作会写一个Cookie。
注意：本文不讨论无Cookie模式的Forms登录。

从前面的截图我们可以看出：虽然当前用户名是 Fish ，但是，Cookie的值是一串乱码样的字符串。
由于安全性的考虑，ASP.NET对Cookie做过加密处理了，这样可以防止恶意用户构造Cookie绕过登录机制来模拟登录用户。如果想知道这串加密字符串是如何得到的，那么请参考后文。

小结：
1. Forms身份认证是在web.config中指定的，我们还可以设置Forms身份认证的其它配置参数。
2. Forms身份认证的登录状态是通过Cookie来维持的。
3. Forms身份认证的登录Cookie是加密的。

理解Forms身份认证

经过前面的Cookie分析，我们可以发现Cookie的值是一串加密后的字符串，现在我们就来分析这个加密过程以及Cookie对于身份认证的作用。

登录的操作通常会检查用户提供的用户名和密码，因此登录状态也必须具有足够高的安全性。在Forms身份认证中，由于登录状态是保存在Cookie中，而Cookie又会保存到客户端，因此，为了保证登录状态不被恶意用户伪造，ASP.NET采用了加密的方式保存登录状态。为了实现安全性，ASP.NET采用【Forms身份验证凭据】（即FormsAuthenticationTicket对象）来表示一个Forms登录用户，加密与解密由FormsAuthentication的Encrypt与Decrypt的方法来实现。

用户登录的过程大致是这样的：
1. 检查用户提交的登录名和密码是否正确。
2. 根据登录名创建一个FormsAuthenticationTicket对象。
3. 调用FormsAuthentication.Encrypt()加密。
4. 根据加密结果创建登录Cookie，并写入Response。
在登录验证结束后，一般会产生重定向操作，那么后面的每次请求将带上前面产生的加密Cookie，供服务器来验证每次请求的登录状态。

每次请求时的（认证）处理过程如下：
1. FormsAuthenticationModule尝试读取登录Cookie。
2. 从Cookie中解析出FormsAuthenticationTicket对象。过期的对象将被忽略。
3. 根据FormsAuthenticationTicket对象构造FormsIdentity对象并设置HttpContext.User
4. UrlAuthorizationModule执行授权检查。

在登录与认证的实现中，FormsAuthenticationTicket和FormsAuthentication是二个核心的类型，前者可以认为是一个数据结构，后者可认为是处理前者的工具类。

UrlAuthorizationModule是一个授权检查模块，其实它与登录认证的关系较为独立，因此，如果我们不使用这种基于用户名与用户组的授权检查，也可以禁用这个模块。

由于Cookie本身有过期的特点，然而为了安全，FormsAuthenticationTicket也支持过期策略，不过，ASP.NET的默认设置支持FormsAuthenticationTicket的可调过期行为，即：slidingExpiration=true 。这二者任何一个过期时，都将导致登录状态无效。

FormsAuthenticationTicket的可调过期的主要判断逻辑由FormsAuthentication.RenewTicketIfOld方法实现，代码如下：

public static FormsAuthenticationTicket RenewTicketIfOld(FormsAuthenticationTicket tOld)
{
// 这段代码是意思是：当指定的超时时间逝去大半时将更新FormsAuthenticationTicket对象。

if( tOld == null )
return null;

DateTime now = DateTime.Now;
TimeSpan span = (TimeSpan)(now - tOld.IssueDate);
TimeSpan span2 = (TimeSpan)(tOld.Expiration - now);
if( span2 > span )
return tOld;

return new FormsAuthenticationTicket(tOld.Version, tOld.Name,
now, now + (tOld.Expiration - tOld.IssueDate),
tOld.IsPersistent, tOld.UserData, tOld.CookiePath);
}

Request.IsAuthenticated可以告诉我们当前请求是否已经过身份验证，我们来看一下这个属性是如何实现的：

public bool IsAuthenticated
{
get
{
return (((this._context.User != null)
&& (this._context.User.Identity != null))
&& this._context.User.Identity.IsAuthenticated);
}
}

从代码可以看出，它的返回结果基本上来源于对Context.User的判断。
另外，由于User和Identity都是二个接口类型的属性，因此，不同的实现方式对返回值也有影响。

由于可能会经常使用HttpContext.User这个实例属性，为了让它能正常使用，DefaultAuthenticationModule会在ASP.NET管线的PostAuthenticateRequest事件中检查此属性是否为null，如果它为null，DefaultAuthenticationModule会给它一个默认的GenericPrincipal对象，此对象指示一个未登录的用户。

我认为ASP.NET的身份认证的最核心部分其实就是HttpContext.User这个属性所指向的对象。
为了更好了理解Forms身份认证，我认为自己重新实现User这个对象的接口会有较好的帮助。

实现自定义的身份认证标识

前面演示了最简单的ASP.NET Forms身份认证的实现方法，即：直接调用SetAuthCookie方法。不过调用这个方法，只能传递一个登录名。但是有时候为了方便后续的请求处理，还需要保存一些与登录名相关的额外信息。虽然知道ASP.NET使用Cookie来保存登录名状态信息，我们也可以直接将前面所说的额外信息直接保存在Cookie中，但是考虑安全性，我们还需要设计一些加密方法，而且还需要考虑这些额外信息保存在哪里才能方便使用，并还要考虑随登录与注销同步修改。因此，实现这些操作还是有点繁琐的。

为了保存与登录名相关的额外的用户信息，我认为实现自定义的身份认证标识（HttpContext.User实例）是个容易的解决方法。
理解这个方法也会让我们对Forms身份认证有着更清楚地认识。

这个方法的核心是（分为二个子过程）：
1. 在登录时，创建自定义的FormsAuthenticationTicket对象，它包含了用户信息。
2. 加密FormsAuthenticationTicket对象。
3. 创建登录Cookie，它将包含FormsAuthenticationTicket对象加密后的结果。
4. 在管线的早期阶段，读取登录Cookie，如果有，则解密。
5. 从解密后的FormsAuthenticationTicket对象中还原我们保存的用户信息。
6. 设置HttpContext.User为我们自定义的对象。

现在，我们还是来看一下HttpContext.User这个属性的定义：

// 为当前 HTTP 请求获取或设置安全信息。
//
// 返回结果:
// 当前 HTTP 请求的安全信息。
public IPrincipal User { get; set; }

由于这个属性只是个接口类型，因此，我们也可以自己实现这个接口。
考虑到更好的通用性：不同的项目可能要求接受不同的用户信息类型。所以，我定义了一个泛型类。

public class MyFormsPrincipal<TUserData> : IPrincipal
where TUserData : class, new()
{
private IIdentity _identity;
private TUserData _userData;

public MyFormsPrincipal(FormsAuthenticationTicket ticket, TUserData userData)
{
if( ticket == null )
throw new ArgumentNullException("ticket");
if( userData == null )
throw new ArgumentNullException("userData");

_identity = new FormsIdentity(ticket);
_userData = userData;
}

public TUserData UserData
{
get { return _userData; }
}

public IIdentity Identity
{
get { return _identity; }
}

public bool IsInRole(string role)
{
// 把判断用户组的操作留给UserData去实现。

IPrincipal principal = _userData as IPrincipal;
if( principal == null )
throw new NotImplementedException();
else
return principal.IsInRole(role);
}

与之配套使用的用户信息的类型定义如下（可以根据实际情况来定义）：

public class UserInfo : IPrincipal
{
public int UserId;
public int GroupId;
public string UserName;

// 如果还有其它的用户信息，可以继续添加。

public override string ToString()
{
return string.Format("UserId: {0}, GroupId: {1}, UserName: {2}, IsAdmin: {3}",
UserId, GroupId, UserName, IsInRole("Admin"));
}

#region IPrincipal Members

[ScriptIgnore]
public IIdentity Identity
{
get { throw new NotImplementedException(); }
}

public bool IsInRole(string role)
{
if( string.Compare(role, "Admin", true) == 0 )
return GroupId == 1;
else
return GroupId > 0;
}

#endregion
}

注意：表示用户信息的类型并不要求一定要实现IPrincipal接口，如果不需要用户组的判断，可以不实现这个接口。

登录时需要调用的方法（定义在MyFormsPrincipal类型中）：

/// <summary>
/// 执行用户登录操作
/// </summary>
/// <param name="loginName">登录名</param>
/// <param name="userData">与登录名相关的用户信息</param>
/// <param name="expiration">登录Cookie的过期时间，单位：分钟。</param>
public static void SignIn(string loginName, TUserData userData, int expiration)
{
if( string.IsNullOrEmpty(loginName) )
throw new ArgumentNullException("loginName");
if( userData == null )
throw new ArgumentNullException("userData");

// 1. 把需要保存的用户数据转成一个字符串。
string data = null;
if( userData != null )
data = (new JavaScriptSerializer()).Serialize(userData);

// 2. 创建一个FormsAuthenticationTicket，它包含登录名以及额外的用户数据。
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
2, loginName, DateTime.Now, DateTime.Now.AddDays(1), true, data);

// 3. 加密Ticket，变成一个加密的字符串。
string cookieValue = FormsAuthentication.Encrypt(ticket);

// 4. 根据加密结果创建登录Cookie
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, cookieValue);
cookie.HttpOnly = true;
cookie.Secure = FormsAuthentication.RequireSSL;
cookie.Domain = FormsAuthentication.CookieDomain;
cookie.Path = FormsAuthentication.FormsCookiePath;
if( expiration > 0 )
cookie.Expires = DateTime.Now.AddMinutes(expiration);

HttpContext context = HttpContext.Current;
if( context == null )
throw new InvalidOperationException();

// 5. 写登录Cookie
context.Response.Cookies.Remove(cookie.Name);
context.Response.Cookies.Add(cookie);
}

这里有必要再补充一下：登录状态是有过期限制的。Cookie有有效期，FormsAuthenticationTicket对象也有有效期。这二者任何一个过期时，都将导致登录状态无效。按照默认设置，FormsAuthenticationModule将采用slidingExpiration=true的策略来处理FormsAuthenticationTicket过期问题。

登录页面代码：

<fieldset><legend>包含【用户信息】的自定义登录</legend> <form action="<%= Request.RawUrl %>" method="post">
<table border="0">
<tr><td>登录名：</td>
<td><input type="text" name="loginName" style="width: 200px" value="Fish" /></td></tr>
<tr><td>UserId：</td>
<td><input type="text" name="UserId" style="width: 200px" value="78" /></td></tr>
<tr><td>GroupId：</td>
<td><input type="text" name="GroupId" style="width: 200px" />
1表示管理员用户
</td></tr>
<tr><td>用户全名：</td>
<td><input type="text" name="UserName" style="width: 200px" value="Fish Li" /></td></tr>
</table>
<input type="submit" name="CustomizeLogin" value="登录" />
</form></fieldset>

登录处理代码：

public void CustomizeLogin()
{
// -----------------------------------------------------------------
// 注意：演示代码为了简单，这里不检查用户名与密码是否正确。
// -----------------------------------------------------------------

string loginName = Request.Form["loginName"];
if( string.IsNullOrEmpty(loginName) )
return;

UserInfo userinfo = new UserInfo();
int.TryParse(Request.Form["UserId"], out userinfo.UserId);
int.TryParse(Request.Form["GroupId"], out userinfo.GroupId);
userinfo.UserName = Request.Form["UserName"];

// 登录状态100分钟内有效
MyFormsPrincipal<UserInfo>.SignIn(loginName, userinfo, 100);

TryRedirect();
}

显示用户信息的页面代码：

<fieldset><legend>用户状态</legend><form action="<%= Request.RawUrl %>" method="post">
<% if( Request.IsAuthenticated ) { %>
当前用户已登录，登录名：<%= Context.User.Identity.Name.HtmlEncode() %> <br />

<% var user = Context.User as MyFormsPrincipal<UserInfo>; %>
<% if( user != null ) { %>
<%= user.UserData.ToString().HtmlEncode() %>
<% } %>

<input type="submit" name="Logon" value="退出" />
<% } else { %>
<b>当前用户还未登录。</b>
<% } %>
</form></fieldset>

为了能让上面的页面代码发挥工作，必须在页面显示前重新设置HttpContext.User对象。
为此，我在Global.asax中添加了一个事件处理器：

protected void Application_AuthenticateRequest(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
MyFormsPrincipal<UserInfo>.TrySetUserInfo(app.Context);
}

TrySetUserInfo的实现代码：

/// <summary>
/// 根据HttpContext对象设置用户标识对象
/// </summary>
/// <param name="context"></param>
public static void TrySetUserInfo(HttpContext context)
{
if( context == null )
throw new ArgumentNullException("context");

// 1. 读登录Cookie
HttpCookie cookie = context.Request.Cookies[FormsAuthentication.FormsCookieName];
if( cookie == null || string.IsNullOrEmpty(cookie.Value) )
return;

try {
TUserData userData = null;
// 2. 解密Cookie值，获取FormsAuthenticationTicket对象
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(cookie.Value);

if( ticket != null && string.IsNullOrEmpty(ticket.UserData) == false )
// 3. 还原用户数据
userData = (new JavaScriptSerializer()).Deserialize<TUserData>(ticket.UserData);

if( ticket != null && userData != null )
// 4. 构造我们的MyFormsPrincipal实例，重新给context.User赋值。
context.User = new MyFormsPrincipal<TUserData>(ticket, userData);
}
catch { /* 有异常也不要抛出，防止攻击者试探。 */ }
}

在多台服务器之间使用Forms身份认证

默认情况下，ASP.NET 生成随机密钥并将其存储在本地安全机构 (LSA) 中，因此，当需要在多台机器之间使用Forms身份认证时，就不能再使用随机生成密钥的方式，需要我们手工指定，保证每台机器的密钥是一致的。

用于Forms身份认证的密钥可以在web.config的machineKey配置节中指定，我们还可以指定加密解密算法：

关于这二个属性，MSDN有如下解释：

在客户端程序中访问受限页面

这一小节送给所有对自动化测试感兴趣的朋友。

有时我们需要用代码访问某些页面，比如：希望用代码测试服务端的响应。

如果是简单的页面，或者页面允许所有客户端访问，这样不会有问题，但是，如果此时我们要访问的页面是一个受限页面，那么就必须也要像人工操作那样：先访问登录页面，提交登录数据，获取服务端生成的登录Cookie，接下来才能去访问其它的受限页面（但要带上登录Cookie）。

注意：由于登录Cookie通常是加密的，且会发生变化，因此直接在代码中硬编码指定登录Cookie会导致代码难以维护。

在前面的示例中，我已在web.config为MyInfo.aspx设置过禁止匿名访问，如果我用下面的代码去调用：

private static readonly string MyInfoPageUrl = "http://localhost:51855/MyInfo.aspx";

static void Main(string[] args)
{
// 这个调用得到的结果其实是default.aspx页面的输出，并非MyInfo.aspx
HttpWebRequest request = MyHttpClient.CreateHttpWebRequest(MyInfoPageUrl);
string html = MyHttpClient.GetResponseText(request);

if( html.IndexOf("<span>Fish</span>") > 0 )
Console.WriteLine("调用成功。");
else
Console.WriteLine("页面结果不符合预期。");
}

此时，输出的结果将会是：

页面结果不符合预期。

如果我用下面的代码：

private static readonly string LoginUrl = "http://localhost:51855/default.aspx";
private static readonly string MyInfoPageUrl = "http://localhost:51855/MyInfo.aspx";

static void Main(string[] args)
{
// 创建一个CookieContainer实例，供多次请求之间共享Cookie
CookieContainer cookieContainer = new CookieContainer();

// 首先去登录页面登录
MyHttpClient.HttpPost(LoginUrl, "NormalLogin=aa&loginName=Fish", cookieContainer);

// 此时cookieContainer已经包含了服务端生成的登录Cookie

// 再去访问要请求的页面。
string html = MyHttpClient.HttpGet(MyInfoPageUrl, cookieContainer);

if( html.IndexOf("<span>Fish</span>") > 0 )
Console.WriteLine("调用成功。");
else
Console.WriteLine("页面结果不符合预期。");

// 如果还要访问其它的受限页面，可以继续调用。
}

此时，输出的结果将会是：

调用成功。

说明：在改进的版本中，我首先创建一个CookieContainer实例，它可以在HTTP调用过程中接收服务器产生的Cookie，并能在发送HTTP请求时将已经保存的Cookie再发送给服务端。在创建好CookieContainer实例之后，每次使用HttpWebRequest对象时，只要将CookieContainer实例赋值给HttpWebRequest对象的CookieContainer属性，即可实现在多次的HTTP调用中Cookie的接收与发送，最终可以模拟浏览器的Cookie处理行为，服务端也能正确识别客户的身份。

ASP.NET Forms身份认证就说到这里，如果您对ASP.NET Windows身份认证有兴趣，那么请关注我的后续博客。

点击此处下载示例代码

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

Fish Li 的一年博客总结

2012-03-12T12:29:00Z

2011-03-12开博，今天2012-03-12，整整写了一年的博客，今天决定写个总结。

这篇总结为分四个部分：
1. 博客索引：谈谈技术，给博客做个索引。
2. 回顾经历：讲述我的写博历程。
3. 博客定位：公开我的博客风格以及选题范围。
4. 规划未来：介绍我未来的写作计划。

博客索引

我的博客在选题时，都选择的是一些基础内容。
下面我从技术的角度，将博客做个分类索引。

在ASP.NET程序中，能够在服务端读取的客户端数据通常只有三个：QueryString, Form, Cookie
关于这三者，我写了三篇博客详细地介绍过它们：
1. 细说Cookie
2. 细说 Form (表单)
3. 细说 Request[]与Request.Params[]

要想把ASP.NET用得顺手，我认为掌握一些ASP.NET核心对象也是必须的，
可以参考我的博客：我心目中的Asp.net核心对象

ASP.NET的管线也是非常重要的，了解它就能更好地理解ASP.NET的处理机制。
可以参考我的博客：用Asp.net写自己的服务框架

除了以上这些核心之外，如果您打算基于ASP.NET开发一些工具类库，
那么，了解下面博客中的内容也有很有帮助的：
1. 细说 ASP.NET Cache 及其高级用法
2. 细说 HttpHandler 的映射过程
3. 在.net中读写config文件的各种方法
4. 细说 ASP.NET控制HTTP缓存

如果您需要基于ASP.NET平台设计自己的框架，那么可以参考下面的博客：
1. 写自己的ASP.NET MVC框架（上）
2. 写自己的ASP.NET MVC框架（下）
3. 用Asp.net写自己的服务框架

异步也有个很有用的东西哦，如果想了解这方面的知识，可以阅读下面的博客：
1. C#客户端的异步操作
2. 细说ASP.NET的各种异步操作

您对性能优化感兴趣吗？如果有兴趣，可以阅读下面的博客：
1. 看懂SqlServer查询计划
2. ASP.NET页面优化，性能提升８倍的方法

您对 NoSQL 数据库有兴趣吗？我也写过这方面的博客：
MongoDB实战开发【零基础学习，附完整Asp.net示例】

写完了ASP.NET项目，您知道如何部署它们吗？如果不清楚，可以参考下面的博客：
如何在IIS6,7中部署ASP.NET网站

回顾经历

2011-03-12，我在博客园注册了一个帐号，从此开始我的写博的经历。

刚开始，只是想晒晒自己的一点小作品（一直都是可下载的），于是发了一系列的灌水贴，最重要的有三篇：
1. 晒晒我的Ajax服务端框架
2. 晒晒我的通用数据访问层
3. 通用数据访问层及Ajax服务端框架的综合示例，展示与下载
由于以前从未写过博客，风格也是模仿他人的风格：短篇+系列的形式。
我数了一下，这类灌水贴有13篇。

虽然这些博客也属于技术博客，而且我还写过博客说明它们的实现原理，但我把它们称为灌水贴是因为：
它们与我后期的博客相比，感觉实在是在灌水。

我对灌水贴还有另一个衡量指标：访问量以及推荐数量较低。
早期的这些博客在这二个指标上，实在是不及格。

2011-06-06，迎来了我的博客发展史的转折点，我发了一篇博客：看懂SqlServer查询计划，
从此，我的博客被博客园称为：推荐博客。
也从这时起，我的博客的访问量才有了一定的增长。

我的博客的另一个重要里程碑来自于我在2011-07-03发布的一篇博客：细说Cookie，
在2011-07-17，我又发了另一篇博客：细说 Form (表单)
从此，我的博客的访问量以及推荐数量均得到较大的提升。

在2011-08-21和2011-09-05，我又分别发了二篇博客：我心目中的Asp.net核心对象 和 用Asp.net写自己的服务框架，
这二篇博客的推出，将我的博客推向鼎盛时期。
这二篇博客现在一直在我的博客的【阅读排行榜】和【推荐排行榜】占据着前二名的位置，而且它们的 推荐次数已超过 300 。

其实这二篇博客并非孤立的，而是都属于我当时规划的一个系列。
为了让后续的博客更精彩，我又花了二个月的时间写了二篇我认为很有价值的博客：
C#客户端的异步操作 和 细说ASP.NET的各种异步操作，
我认为它们很有价值的原因是因为：我在二篇博客中对【异步】做了较为全面细致地总结，
这些内容肯定是在许多的技术书上是找不到的，包含像【CLR via C#】这样的书。

不过，让我没想到的是：这二篇博客（起初）并不受欢迎。
从博客的回复中我也发现：有些人问我为什么不说XXX这类多线程的东西。
其实我也很郁闷啊：难道多线程就是异步吗？

随着时间的推移，我又发了几篇博客，让我意外的是：在.net中读写config文件的各种方法 和 细说 ASP.NET Cache 及其高级用法，
这二篇博客的访问量都已过万（3个月的时间），推荐次数已超200 ，看到这个成绩，真是我当时没想到的。

最近，我又写了一个大的系列博客：MyMVC框架，有兴趣的可以去阅读并下载所有源代码。

博客定位

前面以流水帐的形式讲述了我的写博经历，这里再来谈谈我的博客定位。

在我写完 细说Cookie，细说 Form (表单)之后，我总算知道为什么我早期的博客不受欢迎的原因：定位不正确。

所以，从那时起，我就对我的博客有了一个明确的定位：
1. 只写一些基础话题，但要写出深度。
2. 不写过于简单的话题。诸如一些server控件的使用。
3. 别人写过的话题，除非我能写出更多的内涵，否则不写。
4. 尽量选择一些经得起时间流逝的话题，我希望能留下一些经典。
5. 不搞短篇连载，我认为博客应该更像有内涵的文章而不是向微博发展。

以上5点也可以用4个字来概括：基础，精品：
基础：博客话题以基础技术点为主，因为基础的内容不仅仅重要，而且不会过时。
精品：精品博客是我的追求目标，我更希望若干年后能留下几篇经典的博客。

在写博客的过程中，也有人建议我：为什么不把博客写成XXX系列的？
其实我认为，我一直在写一个系列，一个大的系列：ASP.NET系列。

规划未来

写作是一种总结，总结就会有收获。

分享是件有意义的事情，可以让自己留在别人心里。

未来我将继续总结并与大家分享我的总结成果。

未来的博客规划中，上半年将仍以ASP.NET为主，因为我感觉我还没说完......

在此，我要感谢那些关注我的园友们，谢谢你们。

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

ASP.NET页面优化，性能提升８倍的方法

2012-03-11T12:10:00Z

今天与大家分享：一种优化页面执行速度的方法。
采用这个方法，可以使用页面的执行速度获得【８倍】的提升效果。

为了让您对优化的效果有个直观的了解，我准备了下面的测试结果截图：

测试环境：
1. Windows Server 2003 SP2
2. Viaual Studio 2008，使用自带的WebDev.WebServer.EXE运行网站程序。
3. (ThinkPad SL510)：Core2 T6670 2.2GHz, 4G内存

二个红框中的数字反映了优化前后的执行时间。
数字表明：优化前后，执行时间有了8倍多的差别。

本文的测试结果也仅仅只是一个参考数字，这个结果也只是根据我所设计的测试页面得出的。
优化的过程中，如果不使用服务器控件，那么给GC减少的压力其实也是无法测试到的。
在测试过程中，我还发现测试结果并不是很稳定，因此截图具有一定的偶然性。
测试页面或许在某些方面存在一些片面性，因此，结果仅供参考。

测试背景

看过了优化结果，再来介绍一下：这个测试到底是在测试什么东西？

现在有很多做ASP.NET的开发人员，应该都是从ASP.NET的WebForm编程模型开始学习的。大家都很喜欢用服务器控件，不管输出什么，都会使用服务器控件。有时候为了让页面呈现干净的HTML代码，有些人会选择使用Repeater，Literal这类简单的服务器控件。或许有些人认为：我已不使用GridView这样强大复杂的控件，页面执行速度已经很快了。

真是这样吗？

今天测试的起点就从使用简单的服务器开始，我会分二次对它做一系列的性能优化。
最终就是上图中的3个结果，它们反映了二次优化的改进过程。

在继续介绍之前，有一点我想有必要说明一下：

优化的过程涉及到ASP.NET服务器控件的使用，测试结果也仅仅只是一个参考数字。
如果您认为您的开发工作非常依赖于服务器控件的使用，
那么测试结果对您来说其实是无意义的，请不要在意这个结果。

测试方法

在这次优化过程中，我并没有设计很复杂的测试页面，而是一个很简单的测试页面，页面显示效果如下：

这个页面其实就是显示了一堆超链接，它们来自于我的博客侧边栏的【推荐排行榜】，总共有20条记录，我让页面重复5次输出，也就是生成了100个超链接。

测试的数据是这样获取的：
我复制了我的博客侧边栏的【推荐排行榜】的那段HTML代码，保存到一个文件中：

然后，网站在初始化时，从这段HTML代码提取链接地址以及显示文字，保存到一个BlogInfo的列表中，代码如下：

public class BlogInfo
{
public string Title;
public string Href;
}

public static class XmlDb
{
public static List<BlogInfo> Blogs { get; private set; }

public static void LoadBlogs()
{
string filePath = Path.Combine(HttpRuntime.AppDomainAppPath, @"App_Data\RecommendList.html");

XElement html = XElement.Parse(System.IO.File.ReadAllText(filePath));

Blogs =
(from a in html.Elements("li").Elements("a")
select new BlogInfo { Title = a.Value, Href = a.Attribute("href").Value }).ToList();
}
}

测试时，就把XmlDb.Blogs的内容显示在网页中。
我想这个测试还是比较接近于现实开发的。

这里又有一个问题：我如何测试页面的执行速度？

虽然说创建HttpWebRequest访问页面是个很简单的方法，但我并不打算这样做。
因为从HttpWebRequest发起调用到获取结果，这其中除了有页面的执行时间，还混杂较多的额外调用开销。最终，我选择了在一次HTTP请求中，循环调用Server.Execute来执行页面，并统计时间的方式。其实如何选择测试方法，对于二个测试对象还说，都是公平的。只是说：尽量减少一些额外的调用开销，会让测试结果的差异更大，也更明显。

说明：为了测试代码写起来简单，我使用了MyMVC框架。

测试用例１：WebFromPage.aspx

前面介绍了测试背景以及测试方法。现在就来介绍第1个测试用例，它采用了WebForm编程模型中最经典的写法。

页面代码：

<%@ Page Language="C#" CodeFile="WebFromPage.aspx.cs" Inherits="TestPage_WebFromPage" %>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>PagePerformanceTest http://www.cnblogs.com/fish-li/</title>
</head>
<body>

<p>This is WebFromPage.aspx</p>

<asp:Repeater ID="repeater1" runat="server" onitemdatabound="repeater1_ItemDataBound">
<ItemTemplate>
<asp:HyperLink ID="link1" runat="server"></asp:HyperLink><br />
</ItemTemplate>
<FooterTemplate><hr /></FooterTemplate>
</asp:Repeater>

<asp:Repeater ID="repeater2" runat="server" onitemdatabound="repeater1_ItemDataBound">
<ItemTemplate>
<asp:HyperLink ID="link1" runat="server"></asp:HyperLink><br />
</ItemTemplate>
<FooterTemplate><hr /></FooterTemplate>
</asp:Repeater>

<asp:Repeater ID="repeater3" runat="server" onitemdatabound="repeater1_ItemDataBound">
<ItemTemplate>
<asp:HyperLink ID="link1" runat="server"></asp:HyperLink><br />
</ItemTemplate>
<FooterTemplate><hr /></FooterTemplate>
</asp:Repeater>

<asp:Repeater ID="repeater4" runat="server" onitemdatabound="repeater1_ItemDataBound">
<ItemTemplate>
<asp:HyperLink ID="link1" runat="server"></asp:HyperLink><br />
</ItemTemplate>
<FooterTemplate><hr /></FooterTemplate>
</asp:Repeater>

<asp:Repeater ID="repeater5" runat="server" onitemdatabound="repeater1_ItemDataBound">
<ItemTemplate>
<asp:HyperLink ID="link1" runat="server"></asp:HyperLink><br />
</ItemTemplate>
<FooterTemplate><hr /></FooterTemplate>
</asp:Repeater>

</body>
</html>

页面的CodeFile代码：

public partial class TestPage_WebFromPage : System.Web.UI.Page
{
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);

repeater1.DataSource = XmlDb.Blogs;
repeater1.DataBind();
repeater2.DataSource = XmlDb.Blogs;
repeater2.DataBind();
repeater3.DataSource = XmlDb.Blogs;
repeater3.DataBind();
repeater4.DataSource = XmlDb.Blogs;
repeater4.DataBind();
repeater5.DataSource = XmlDb.Blogs;
repeater5.DataBind();
}

protected void repeater1_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
if( e.Item.ItemType == ListItemType.Item ) {
BlogInfo blog = e.Item.DataItem as BlogInfo;
HyperLink link1 = e.Item.FindControl("link1") as HyperLink;
link1.NavigateUrl = blog.Href;
link1.Text = blog.Title;
}
}
}

测试代码：

[Action]
public object Test1(string callTimes)
{
int count = 0;
int.TryParse(callTimes, out count);
if( count <= 0 )
return count;

HttpContext context = HttpContext.Current;

// 先执行一次，排除编译时间
string html = MyMVC.PageExecutor.Render(context, "/TestPage/WebFromPage.aspx", null);

Stopwatch watch = Stopwatch.StartNew();
for( int i = 0; i < count; i++ )
html = MyMVC.PageExecutor.Render(context, "/TestPage/WebFromPage.aspx", null);
watch.Stop();

return watch.Elapsed.ToString();
}

当我测试执行10000次时，耗时：00:00:07.5607229

测试用例２：InlinePage.aspx

与测试用例1不同，测试用例2则完全不使用服务器控件。

页面代码：

<%@ Page Language="C#" %>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>PagePerformanceTest http://www.cnblogs.com/fish-li/</title>
</head>
<body>

<p>This is InlinePage.aspx</p>

<% foreach( BlogInfo b in XmlDb.Blogs ) { %>
<a href="<%= b.Href %>" target="_blank"><%= b.Title %></a><br />
<% } %>
<hr />

<% foreach( BlogInfo b in XmlDb.Blogs ) { %>
<a href="<%= b.Href %>" target="_blank"><%= b.Title %></a><br />
<% } %>
<hr />

<% foreach( BlogInfo b in XmlDb.Blogs ) { %>
<a href="<%= b.Href %>" target="_blank"><%= b.Title %></a><br />
<% } %>
<hr />

<% foreach( BlogInfo b in XmlDb.Blogs ) { %>
<a href="<%= b.Href %>" target="_blank"><%= b.Title %></a><br />
<% } %>
<hr />

<% foreach( BlogInfo b in XmlDb.Blogs ) { %>
<a href="<%= b.Href %>" target="_blank"><%= b.Title %></a><br />
<% } %>
<hr />

</body>
</html>

测试代码：

[Action]
public object Test2(string callTimes)
{
int count = 0;
int.TryParse(callTimes, out count);
if( count <= 0 )
return count;

HttpContext context = HttpContext.Current;

// 先执行一次，排除编译时间
string html = MyMVC.PageExecutor.Render(context, "/TestPage/InlinePage.aspx", null);

Stopwatch watch = Stopwatch.StartNew();
for( int i = 0; i < count; i++ )
html = MyMVC.PageExecutor.Render(context, "/TestPage/InlinePage.aspx", null);
watch.Stop();

return watch.Elapsed.ToString();
}

当我测试执行10000次时，耗时：00:00:01.2345842

分析优化结果１

测试用例1执行相同次数所花费的时间是测试用例2的6倍，为什么会这样呢？

为了回答这个问题，我们首先要知道前面二个页面在执行时，它们是如何运行的。
说到这里，就不得不谈ASP.NET的页面编译方式了。

ASP.NET的页面编译过程是个复杂的操作，其实我们可以不用关心页面是如何编译的，
但要知道：页面编译后是什么样的。

为了能直观地了解页面编译后的样子，我编译了整个网站，并生成到一个DLL文件中，然后使用Reflector.exe来分析这个DLL的源代码。

将网站编译成一个DLL文件有二个方法：
1. 安装WebDeployment插件。
2. 使用我的工具：FishAspnetTool。

在编译网站之后，我就可以知道网站在运行时如何运行页面了。

测试用例1的页面，最后被编译成这样了：

namespace ASP
{
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

[CompilerGlobalScope]
public class testpage_webfrompage_aspx : TestPage_WebFromPage, IHttpHandler
{
private static object __fileDependencies;
private static bool __initialized;

[DebuggerNonUserCode]
public testpage_webfrompage_aspx()
{
base.AppRelativeVirtualPath = "~/TestPage/WebFromPage.aspx";
if (!__initialized)
{
string[] virtualFileDependencies = new string[] { "~/TestPage/WebFromPage.aspx", "~/TestPage/WebFromPage.aspx.cs" };
__fileDependencies = base.GetWrappedFileDependencies(virtualFileDependencies);
__initialized = true;
}
base.Server.ScriptTimeout = 0x1c9c380;
}

[DebuggerNonUserCode]
private void __BuildControl__control10(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("<hr />"));
}

[DebuggerNonUserCode]
private void __BuildControl__control11(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\t"));
HyperLink link = this.__BuildControl__control12();
accessor.AddParsedSubObject(link);
accessor.AddParsedSubObject(new LiteralControl("<br />\r\n"));
}

[DebuggerNonUserCode]
private HyperLink __BuildControl__control12()
{
HyperLink link = new HyperLink {
TemplateControl = this
};
link.ApplyStyleSheetSkin(this);
link.ID = "link1";
return link;
}

[DebuggerNonUserCode]
private void __BuildControl__control13(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("<hr />"));
}

[DebuggerNonUserCode]
private void __BuildControl__control14(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\t"));
HyperLink link = this.__BuildControl__control15();
accessor.AddParsedSubObject(link);
accessor.AddParsedSubObject(new LiteralControl("<br />\r\n"));
}

[DebuggerNonUserCode]
private HyperLink __BuildControl__control15()
{
HyperLink link = new HyperLink {
TemplateControl = this
};
link.ApplyStyleSheetSkin(this);
link.ID = "link1";
return link;
}

[DebuggerNonUserCode]
private void __BuildControl__control16(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("<hr />"));
}

[DebuggerNonUserCode]
private void __BuildControl__control2(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\t"));
HyperLink link = this.__BuildControl__control3();
accessor.AddParsedSubObject(link);
accessor.AddParsedSubObject(new LiteralControl("<br />\r\n"));
}

[DebuggerNonUserCode]
private HyperLink __BuildControl__control3()
{
HyperLink link = new HyperLink {
TemplateControl = this
};
link.ApplyStyleSheetSkin(this);
link.ID = "link1";
return link;
}

[DebuggerNonUserCode]
private void __BuildControl__control4(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("<hr />"));
}

[DebuggerNonUserCode]
private void __BuildControl__control5(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\t"));
HyperLink link = this.__BuildControl__control6();
accessor.AddParsedSubObject(link);
accessor.AddParsedSubObject(new LiteralControl("<br />\r\n"));
}

[DebuggerNonUserCode]
private HyperLink __BuildControl__control6()
{
HyperLink link = new HyperLink {
TemplateControl = this
};
link.ApplyStyleSheetSkin(this);
link.ID = "link1";
return link;
}

[DebuggerNonUserCode]
private void __BuildControl__control7(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("<hr />"));
}

[DebuggerNonUserCode]
private void __BuildControl__control8(Control __ctrl)
{
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\t"));
HyperLink link = this.__BuildControl__control9();
accessor.AddParsedSubObject(link);
accessor.AddParsedSubObject(new LiteralControl("<br />\r\n"));
}

[DebuggerNonUserCode]
private HyperLink __BuildControl__control9()
{
HyperLink link = new HyperLink {
TemplateControl = this
};
link.ApplyStyleSheetSkin(this);
link.ID = "link1";
return link;
}

[DebuggerNonUserCode]
private Repeater __BuildControlrepeater1()
{
Repeater repeater = new Repeater();
base.repeater1 = repeater;
repeater.ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control2));
repeater.FooterTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control4));
repeater.ID = "repeater1";
repeater.ItemDataBound += new RepeaterItemEventHandler(this.repeater1_ItemDataBound);
return repeater;
}

[DebuggerNonUserCode]
private Repeater __BuildControlrepeater2()
{
Repeater repeater = new Repeater();
base.repeater2 = repeater;
repeater.ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control5));
repeater.FooterTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control7));
repeater.ID = "repeater2";
repeater.ItemDataBound += new RepeaterItemEventHandler(this.repeater1_ItemDataBound);
return repeater;
}

[DebuggerNonUserCode]
private Repeater __BuildControlrepeater3()
{
Repeater repeater = new Repeater();
base.repeater3 = repeater;
repeater.ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control8));
repeater.FooterTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control10));
repeater.ID = "repeater3";
repeater.ItemDataBound += new RepeaterItemEventHandler(this.repeater1_ItemDataBound);
return repeater;
}

[DebuggerNonUserCode]
private Repeater __BuildControlrepeater4()
{
Repeater repeater = new Repeater();
base.repeater4 = repeater;
repeater.ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control11));
repeater.FooterTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control13));
repeater.ID = "repeater4";
repeater.ItemDataBound += new RepeaterItemEventHandler(this.repeater1_ItemDataBound);
return repeater;
}

[DebuggerNonUserCode]
private Repeater __BuildControlrepeater5()
{
Repeater repeater = new Repeater();
base.repeater5 = repeater;
repeater.ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control14));
repeater.FooterTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control16));
repeater.ID = "repeater5";
repeater.ItemDataBound += new RepeaterItemEventHandler(this.repeater1_ItemDataBound);
return repeater;
}

[DebuggerNonUserCode]
private void __BuildControlTree(testpage_webfrompage_aspx __ctrl)
{
__ctrl.EnableViewState = false;
__ctrl.EnableViewStateMac = false;
this.InitializeCulture();
IParserAccessor accessor = __ctrl;
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n <title>PagePerformanceTest http://www.cnblogs.com/fish-li/</title>\r\n</head>\r\n<body>\r\n\r\n<p>This is WebFromPage.aspx</p>\r\n\r\n"));
Repeater repeater = this.__BuildControlrepeater1();
accessor.AddParsedSubObject(repeater);
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n"));
Repeater repeater2 = this.__BuildControlrepeater2();
accessor.AddParsedSubObject(repeater2);
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n"));
Repeater repeater3 = this.__BuildControlrepeater3();
accessor.AddParsedSubObject(repeater3);
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n"));
Repeater repeater4 = this.__BuildControlrepeater4();
accessor.AddParsedSubObject(repeater4);
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n"));
Repeater repeater5 = this.__BuildControlrepeater5();
accessor.AddParsedSubObject(repeater5);
accessor.AddParsedSubObject(new LiteralControl("\r\n\r\n\r\n</body>\r\n</html>\r\n"));
}

[DebuggerNonUserCode]
protected override void FrameworkInitialize()
{
base.FrameworkInitialize();
this.__BuildControlTree(this);
base.AddWrappedFileDependencies(__fileDependencies);
base.Request.ValidateInput();
}

[DebuggerNonUserCode]
public override int GetTypeHashCode()
{
return -781896338;
}

[DebuggerNonUserCode]
public override void ProcessRequest(HttpContext context)
{
base.ProcessRequest(context);
}

protected override bool SupportAutoEvents
{
get
{
return false;
}
}
}
}

从这个编译结果我们可以看出：页面上的所有文字最后也被包装到LiteralControl中。
页面中呈现时，就是循环调用每个控件的Render方法来最终生成HTML结果。

测试用例2的页面被编译成这个样了：

namespace ASP
{
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Web;
using System.Web.Profile;
using System.Web.UI;

[CompilerGlobalScope]
public class testpage_inlinepage_aspx : Page, IHttpHandler
{
private static object __fileDependencies;
private static bool __initialized;

[DebuggerNonUserCode]
public testpage_inlinepage_aspx()
{
base.AppRelativeVirtualPath = "~/TestPage/InlinePage.aspx";
if (!__initialized)
{
string[] virtualFileDependencies = new string[] { "~/TestPage/InlinePage.aspx" };
__fileDependencies = base.GetWrappedFileDependencies(virtualFileDependencies);
__initialized = true;
}
base.Server.ScriptTimeout = 0x1c9c380;
}

[DebuggerNonUserCode]
private void __BuildControlTree(testpage_inlinepage_aspx __ctrl)
{
__ctrl.EnableViewState = false;
__ctrl.EnableViewStateMac = false;
this.InitializeCulture();
__ctrl.SetRenderMethodDelegate(new RenderMethod(this.__Render__control1));
}

private void __Render__control1(HtmlTextWriter __w, Control parameterContainer)
{
__w.Write("\r\n\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n <title>PagePerformanceTest http://www.cnblogs.com/fish-li/</title>\r\n</head>\r\n<body>\r\n\r\n<p>This is InlinePage.aspx</p>\r\n\r\n");
foreach (BlogInfo info in XmlDb.Blogs)
{
__w.Write("\r\n\t<a href=\"");
__w.Write(info.Href);
__w.Write("\" target=\"_blank\">");
__w.Write(info.Title);
__w.Write("</a><br />\r\n");
}
__w.Write("\r\n<hr />\r\n\r\n");
foreach (BlogInfo info2 in XmlDb.Blogs)
{
__w.Write("\r\n\t<a href=\"");
__w.Write(info2.Href);
__w.Write("\" target=\"_blank\">");
__w.Write(info2.Title);
__w.Write("</a><br />\r\n");
}
__w.Write("\r\n<hr />\r\n\r\n");
foreach (BlogInfo info3 in XmlDb.Blogs)
{
__w.Write("\r\n\t<a href=\"");
__w.Write(info3.Href);
__w.Write("\" target=\"_blank\">");
__w.Write(info3.Title);
__w.Write("</a><br />\r\n");
}
__w.Write("\r\n<hr />\r\n\r\n");
foreach (BlogInfo info4 in XmlDb.Blogs)
{
__w.Write("\r\n\t<a href=\"");
__w.Write(info4.Href);
__w.Write("\" target=\"_blank\">");
__w.Write(info4.Title);
__w.Write("</a><br />\r\n");
}
__w.Write("\r\n<hr />\r\n\r\n");
foreach (BlogInfo info5 in XmlDb.Blogs)
{
__w.Write("\r\n\t<a href=\"");
__w.Write(info5.Href);
__w.Write("\" target=\"_blank\">");
__w.Write(info5.Title);
__w.Write("</a><br />\r\n");
}
__w.Write("\r\n<hr />\r\n\r\n</body>\r\n</html>\r\n");
}

[DebuggerNonUserCode]
protected override void FrameworkInitialize()
{
base.FrameworkInitialize();
this.__BuildControlTree(this);
base.AddWrappedFileDependencies(__fileDependencies);
base.Request.ValidateInput();
}

[DebuggerNonUserCode]
public override int GetTypeHashCode()
{
return -1307842476;
}

[DebuggerNonUserCode]
public override void ProcessRequest(HttpContext context)
{
base.ProcessRequest(context);
}

protected global_asax ApplicationInstance
{
get
{
return (global_asax) this.Context.ApplicationInstance;
}
}

protected DefaultProfile Profile
{
get
{
return (DefaultProfile) this.Context.Profile;
}
}

protected override bool SupportAutoEvents
{
get
{
return false;
}
}
}
}

请注意下面这段关键的代码：它们实在太重要了。

private void __BuildControlTree(testpage_inlinepage_aspx __ctrl)
{
// .......
__ctrl.SetRenderMethodDelegate(new RenderMethod(this.__Render__control1));
}

private void __Render__control1(HtmlTextWriter __w, Control parameterContainer)
{

testpage_inlinepage_aspx与testpage_webfrompage_aspx的编译结果完全不同。
最大的差别在testpage_inlinepage_aspx有个方法：__Render__control1
在这个方法中，页面的内容将直接被写入到HtmlTextWriter对象中。
还有一点我要告诉您：每个Control的输出最后还是要将自己的显示代码写入到HtmlTextWriter对象中。
因此，从这里就可以明显地看出testpage_inlinepage_aspx的执行速度要快很多，
因为：
1. 它没有服务器控件。
2. 不再需要递归循环每个控件，每个控件的生命周期的调用开销也节省了。
3. 不用再创建那些服务器控件对象，GC的压力会小很多。
4. 输出方式更高效。

通过前面的分析，您现在明白了为什么二个页面的执行速度相差6倍了原因了吧。

好像还有一点没有解释：__Render__control1如何被调用？

我们都知道：以ASPX页面为代表的WebForm编程模型在执行时有一个特点：递归循环每个控件。
页面是在Render阶段输出的，页面的HTML代码也是在那个阶段输出到HtmlTextWriter对象中的。
可是，testpage_inlinepage_aspx没有任何控件，那又该如何递归呢？

的确，很多书籍以及技术资料都是说：在Render阶段会递归循环每个控件并调用控件的Render方法。

其实这种说法是不准确的。Control的Render方法在运行时，会调用下面这个方法：

internal void RenderChildrenInternal(HtmlTextWriter writer, ICollection children)
{
if ((this.RareFields != null) && (this.RareFields.RenderMethod != null))
{
writer.BeginRender();
this.RareFields.RenderMethod(writer, this);
writer.EndRender();
}
else if (children != null)
{
foreach (Control control in children)
{
control.RenderControl(writer);
}
}
}

这段代码中，有个重要的if...else...判断，简单说来，就是说要不要调用前面所说的__Render__control1方法。
从代码可以看出，如果是进入了if语句块，则不用递归循环每个控件并调用控件的Render方法。

那么如何能进入if语句块呢？
答案是：调用Control.SetRenderMethodDelegate方法。
testpage_inlinepage_aspx的编译生成代码中就有这个调用。
对于这个方法，MSDN的解释很含糊：

此 API 支持 .NET Framework 基础结构，不适合在代码中直接使用。

分配事件处理程序委托，以将服务器控件及其内容呈现到父控件中。

测试用例３：InlineUserControl.ascx

在测试用例3中，我将页面中用于输出的代码移到一个用户控件中。
用户控件的代码此处省略，与测试用例2的代码基本上一致。编译后的结果也基本差不多。

测试代码：

[Action]
public object Test3(string callTimes)
{
int count = 0;
int.TryParse(callTimes, out count);
if( count <= 0 )
return count;

// 先执行一次，排除编译时间
string html = MyMVC.UcExecutor.Render("/UserControl/InlineUserControl.ascx", null);

Stopwatch watch = Stopwatch.StartNew();
for( int i = 0; i < count; i++ )
html = MyMVC.UcExecutor.Render("/UserControl/InlineUserControl.ascx", null);
watch.Stop();

return watch.Elapsed.ToString();
}

当我测试执行10000次时，耗时：00:00:00.9132738

又快了一点。

说明：为了这次的性能优化，MyMVC框架也做了一点调整。如果您以前下载过这个框架，请重新下载。

分析优化结果２

经过前面的分析，我们知道：不创建服务器控件对象以及不调用它们的生命周期，可以让页面的执行速度快很多。

有没有再想像一下：页面也有生命周期啊，而且生命周期的步骤更长，省略它，会不会更快呢？

不过，Render方法并不是个public方法，我们还不能直接调用，但可以调用RenderControl方法来实现这一过程。

由于跳过页面的生命周期，任何服务器控件都不能使用了，包括母板页。所以我选择将前面测试用的那段代码移到用户控件中，然后将用户控件加载到Page中来测试。

测试用例3与测试用例2相比，在测试过程中，由于跳过了页面的生命周期，因此速度也就更快了。
注意：事实上，动态加载用户控件也会有一定的调用开销。这种方法也仅供参考，可以根据实际情况来选择。

嗯，基本上，就是这个简单的原因吧。

由于这种方法没有任何的控件生命周期，因此速度是最快的。

经过这一系列的优化，页面的执行时间最终由 00:00:07.5607229 减少到 00:00:00.9132738

再次申明：测试结果也仅仅只是一个参考数字。
事实上，使用服务器控件产生的对象涉及到GC的回收以及内存占用的影响也是不可忽视的。

点击此处下载示例代码

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

用ASP.NET写个SQLSERVER的小工具

2012-03-04T13:24:00Z

2001年4月份，我在博客中发过一个小工具，它是一个用ASP.NET写的SQL SERVER的辅助小工具。在这期间，有些人貌似对那个工具比较有兴趣，所以我常能收到索要源代码的邮件。正好，我上月又发布了我的MVC框架，因此打算用【我的ASP.NET MVC框架】来重写这个工具，并开源。

工具的特点：
1. 采用ASP.NET编写，并借助MyMVC框架。
2. 为了更好地接近桌面程序的操作体验，网站采用纯AJAX的方式实现。
3. 界面使用了 JQuery Easy UI
4. 代码的语法着色使用了 syntaxhighlighter (JavaScript类库)

工具的定位：只是辅助工具，因此功能有限，但要将有限的功能做得尽量好。

下面将分别介绍工具所能完成的功能，以及关键的实现代码。
说明：工具的所有源代码可以在本文的结尾处下载。

项目介绍

整个工具的源代码结构如下：

项目由Visual Studio 2008创建，包含三个部分：

1. WebApp：一个ASP.NET网站，它是工具的可运行部分。
   网站只包含一些HTML, CSS, JavaScript，DLL文件。

2. MyMvcEx：一个类库项目，它提供了MyMVC框架的二个IActionResult接口的实现类，
   用于向浏览器客户端输出DataTable, DataSet

3. SqlServerSmallToolLib：运行网站所需的所有后台代码，
   包括：Controller，BLL类，等等。

MyMVC框架发挥的作用

从前面的项目介绍中，我们可以看到，整个网站没有一个ASPX文件，只有HTML文件，
所有对服务器的调用全由AJAX来实现，比如：下面的【比较数据库】的代码片段：

$.ajax({
cache: false, dataType: "json", type: "GET",
urlstyle="color:red; font-weight: bold;">: style="font-size: large; font-weight: bold">'/AjaxService/CompareDB.cspx',
data:{ srcConnId: $("#hfSrcConnId").val(),
destConnId: $("#hfDestConnId").val(),
srcDB: $("#cboSrcDB").combobox("getValue"),
destDB: $("#cboDestDB").combobox("getValue") ,
flag: flag
},

在服务端，我只要实现这样一个C#方法就可以响应客户端的请求了：

[Action]
public object style="font-size: large; font-weight: bold">CompareDB(string srcConnId, string destConnId, string srcDB, string destDB, string flag)
{
var result = CompareDBHelper.CompareDB(srcConnId, destConnId, srcDB, destDB, flag);
return new JsonResult(result);
}

至于说：JS发起的请求是如何调用到这个C#方法的，以及这个C#方法在调用时的参数和返回值的处理，全由MyMVC框架来实现。
对于开发AJAX来说，可以不用关心这个问题，只要写出一个C#方法给JS调用就可以了。

引用MyMVC是件很简单的事情，只需要在web.config中做如下的配置即可：

再补充一点：如果不喜欢看到Action方法包含较多的输入参数，也可以使用下面的方法：

public class CompareDbOption
{
public string SrcConnId;
public string DestConnId;
public string SrcDb;
public string DestDb;
public string Flag;
}

[Action]
public object CompareDB(CompareDbOption option)
{
var result = CompareDBHelper.CompareDB(option.SrcConnId, option.DestConnId,
option.SrcDb, option.DestDb, option.Flag);
return new JsonResult(result);
}

如果您喜欢在浏览器的客户端中使用jquery以及jquery.form.js插件，
您会发现在服务端再借助MyMVC框架来实现AJAX实在是太方便了。
再来一个添加连接的代码片段：

Html表单代码：

<div id="divConnectionDialog" style="padding:10px; width: 420px; height: 320px; display: none;" title="新增/编辑数据库连接信息">
<form id="formConnection" method="post" style="font-size: large; font-weight: bold">actionstyle="font-size: large; font-weight: bold">="/AjaxService/SubmitConnectionInfo.cspx">

<table cellpadding="4" cellspacing="0" style="width: 100%; border: 0px;">
<tr><td>服务器IP/Name</td><td>
<input id="txtServerIP" name="ServerIP" type="text" class="myTextbox" style="width: 220px" />
</td></tr>
<tr><td>登录方式</td><td>
<select id="cboSSPI" name="SSPI" style="width: 222px" panelWidth="222">
<option value="false">用户名／密码</option>
<option value="true">Windows连接</option>
</select>
</td></tr>
<tr><td>登录名</td><td>
<input id="txtUserName" name="UserName" type="text" class="myTextbox" style="width: 220px" />
</td></tr>
<tr><td>登录密码</td><td>
<input id="txtPassword" name="Password" type="text" class="myTextbox" style="width: 220px" />
</td></tr>
<tr><td></td><td>
<input id="hfConnectionId" name="ConnectionId" type="hidden" value="" />
</td></tr>
</table>
<div><span id="spanWait" style="display: none;" class="waitText">请稍后......</span></div>
</form>
</div>

JavaScript提交表单代码：

function SubmitConnectionForm(){
if( ValidateForm() == false ) return false;
$(style="color:#a31515; font-weight: bold;">"#formConnection").ajaxSubmit({
success: function(responseText, statusText) {
if (responseText == "update OK" ){
$('#divConnectionDialog').dialog('close');
// 省略后面的代码。

服务端C#代码：

[Action]
public string style="font-size: large; font-weight: bold">SubmitConnectionInfo(ConnectionInfo info)
{
if( string.IsNullOrEmpty(info.ServerIP) )
throw new MyMessageException("ServerIP is empty.");

if( info.SSPI == false && string.IsNullOrEmpty(info.UserName) )
throw new MyMessageException("UserName is empty.");

bool isAdd = string.IsNullOrEmpty(info.ConnectionId);

if( isAdd ) {
info.ConnectionId = Guid.NewGuid().ToString();
ConnectionManager.AddConnection(info);
return info.ConnectionId;
}
else {
ConnectionManager.UpdateConnection(info);
return "update OK";
}
}

public sealed class ConnectionInfo
{
public string ConnectionId;
public string ServerIP;
public string UserName;
public string Password;
public bool SSPI;
public int Priority;
}

在整个工具的开发过程中，由于使用了MyMVC框架以及JQuery，AJAX的实现简直是太容易了。

MyMVC框架的下载地址：http://www.cnblogs.com/fish-li/archive/2012/02/21/2361982.html

工具主界面

工具启动后，将能看到下面的主界面：

主界面的左边的【工具列表】中包含二个独立的功能模块。
右边的上方区域是所有的数据库连接的列表。
建议在初次使用时，将自己所需要访问的SQL SERVER连接参数配置好。

这个工具可以管理多个连接，而且会根据连接的使用频率来排序，以方便操作。
如果需要创建一个连接，可以点击工具栏中的【新增连接】按键，将出现以下对话框。

工具可以支持二种连接方式：1. Windows信任连接，2. 用户名/密码连接。

数据库连接列表的部分网页代码：

<div region="center" style="overflow:hidden;" title="数据库连接列表" iconCls="icon-Relation">
<div class="easyui-layout" fit="true" border="false">
<div region="center">
<table id="tblConnList"></table>
</div>
<div region="south" split="true" style="height:220px; padding: 10px;" title="操作说明" iconCls="icon-help">
<p>1. “新增连接”，“删除连接”，“设置连接”用于维护连接记录。</p>
<p>2. “打开连接”将根据选择的连接，打开 Database 对象浏览页面。</p>
</div>
</div>
</div>

连接采用XML文件来保存，相关的操作代码：

internal static class ConnectionManager
{
private static List<ConnectionInfo> s_list = null;
private static readonly Encoding DefaultEncoding = System.Text.Encoding.Unicode;
private static readonly string s_savePath = Path.Combine(HttpRuntime.AppDomainAppPath, @"App_Data\Connection.xml");

static ConnectionManager()
{
try {
string appDataPath = Path.Combine(HttpRuntime.AppDomainAppPath, "App_Data");

if( Directory.Exists(appDataPath) == false )
Directory.CreateDirectory(appDataPath);
}
catch { }
}

[MethodImpl(MethodImplOptions.Synchronized)]
public static List<ConnectionInfo> GetList()
{
EnsureListLoaded();

// 调用这个方法应该会比“修改”的次数会少很多，所以决定在这里排序。
return (from c in s_list orderby c.Priority descending select c).ToList();
}

[MethodImpl(MethodImplOptions.Synchronized)]
public static void AddConnection(ConnectionInfo info)
{
EnsureListLoaded();

s_list.Add(info);
SaveListToFile();
}

[MethodImpl(MethodImplOptions.Synchronized)]
public static void RemoveConnection(string ConnectionId)
{
EnsureListLoaded();

int index = -1;
for( int i = 0; i < s_list.Count; i++ )
if( s_list[i].ConnectionId == ConnectionId ) {
index = i;
break;
}

if( index >= 0 ) {
s_list.RemoveAt(index);
SaveListToFile();
}
}

[MethodImpl(MethodImplOptions.Synchronized)]
public static void UpdateConnection(ConnectionInfo info)
{
EnsureListLoaded();

ConnectionInfo exist = s_list.FirstOrDefault(x => x.ConnectionId == info.ConnectionId);

if( exist != null ) {
exist.ServerIP = info.ServerIP;
exist.UserName = info.UserName;
exist.Password = info.Password;
exist.SSPI = info.SSPI;
// 注意：其它没列出的成员，表示不需要在此更新。
SaveListToFile();
}
}

[MethodImpl(MethodImplOptions.Synchronized)]
public static ConnectionInfo GetConnectionInfoById(string connectionId, bool increasePriority)
{
if( string.IsNullOrEmpty(connectionId) )
throw new ArgumentNullException("connectionId");

EnsureListLoaded();

ConnectionInfo exist = s_list.FirstOrDefault(x => x.ConnectionId == connectionId);
if( exist == null )
throw new MyMessageException("connectionId is invalid.");

if( increasePriority ) {
exist.Priority++;
SaveListToFile();
}
return exist;
}

private static void EnsureListLoaded()
{
if( s_list == null ) {
try {
s_list = XmlHelper.XmlDeserializeFromFile<List<ConnectionInfo>>(s_savePath, DefaultEncoding);
}
catch {
s_list = new List<ConnectionInfo>();
}
}
}

private static void SaveListToFile()
{
if( s_list == null || s_list.Count == 0 ) {
try {
File.Delete(s_savePath);
}
catch { }
}
else {
XmlHelper.XmlSerializeToFile(s_list, s_savePath, DefaultEncoding);
}
}
}

服务端的Action实现代码：

[Action]
public object GetAllConnectionInfo()
{
List<ConnectionInfo> list = ConnectionManager.GetList();

ConnectionInfoDataGridJsonResult result = new ConnectionInfoDataGridJsonResult();
result.total = list.Count;
result.rows = list;

return new JsonResult(result);
}

[Action]
public string SubmitConnectionInfo(ConnectionInfo info)
{
if( string.IsNullOrEmpty(info.ServerIP) )
throw new MyMessageException("ServerIP is empty.");

if( info.SSPI == false && string.IsNullOrEmpty(info.UserName) )
throw new MyMessageException("UserName is empty.");

bool isAdd = string.IsNullOrEmpty(info.ConnectionId);

if( isAdd ) {
info.ConnectionId = Guid.NewGuid().ToString();
ConnectionManager.AddConnection(info);
return info.ConnectionId;
}
else {
ConnectionManager.UpdateConnection(info);
return "update OK";
}

}

[Action]
public void DeleteConnection(string connectionId)
{
if( string.IsNullOrEmpty(connectionId) )
throw new MyMessageException("connectionId is empty.");

ConnectionManager.RemoveConnection(connectionId);
}

[Action]
public string TestConnection(ConnectionInfo info)
{
BaseBLL instance = BaseBLL.GetInstance(null);
return instance.TestConnection(info);
}

Database 浏览器

在主界面的【数据库连接列表】中，选择一个连接，然后点击工具栏上的【打开连接】按键，即可进入【Database 浏览器】界面。

在这个工具中，如果需要查看某个数据库对象的定义，只需要点击相应的对象节点就可以了：

为了操作方便，工具提供多标签查看功能：

获取数据库对象列表的关键代码：

private static readonly string s_QueryDatabaseListScript =
"SELECT dtb.name AS [Database_Name] FROM master.sys.databases AS dtb " +
"WHERE (CAST(case when dtb.name in ('master','model','msdb','tempdb') then 1 else dtb.is_distributor end AS bit)=0 " +
" and CAST(isnull(dtb.source_database_id, 0) AS bit)=0) " +
"ORDER BY [Database_Name] ASC";

protected override List<string> GetDatabaseNames(DbConnection connection)
{
return ExecuteQueryToStringList(connection, s_QueryDatabaseListScript);
}

private static readonly string s_GetObjectNamesFormat =
"select name from ( SELECT obj.name AS [Name], " +
"CAST( case when obj.is_ms_shipped = 1 then 1 " +
" when ( select major_id from sys.extended_properties " +
" where major_id = obj.object_id and minor_id = 0 and class = 1 and name = N'microsoft_database_tools_support') " +
" is not null then 1 else 0 " +
"end AS bit) AS [IsSystemObject] " +
"FROM sys.all_objects AS obj where obj.type in ({0}) )as tables where [IsSystemObject] = 0 ORDER BY [Name] ASC ";

private static readonly string s_ProcedureType = " N'P', N'PC' ";
private static readonly string s_FunctionType = " N'FN', N'IF', N'TF', N'FS', N'FT' ";
private static readonly string s_TableType = " N'U' ";
private static readonly string s_ViewType = " N'V' ";

protected override List<string> GetDbProcedureNames(DbConnection connection)
{
//string sql = "select name from sys.objects where type='P' order by name";
string sql = string.Format(s_GetObjectNamesFormat, s_ProcedureType);
return ExecuteQueryToStringList(connection, sql);
}

protected override List<string> GetDbFunctionNames(DbConnection connection)
{
//string sql = "select name from sys.objects where type='FN' order by name";
string sql = string.Format(s_GetObjectNamesFormat, s_FunctionType);
return ExecuteQueryToStringList(connection, sql);
}

protected override List<string> GetDbTableNames(DbConnection connection)
{
//string sql = "select name from sys.objects where type='U' where name != 'sysdiagrams' order by name";
string sql = string.Format(s_GetObjectNamesFormat, s_TableType);
return ExecuteQueryToStringList(connection, sql);
}

protected override List<string> GetDbViewNames(DbConnection connection)
{
//string sql = "select name from sys.objects where type='V' order by name";
string sql = string.Format(s_GetObjectNamesFormat, s_ViewType);
return ExecuteQueryToStringList(connection, sql);
}

查看数据库对象的定义脚本的实现代码：

protected override ItemCode GetProcedureItem(DbConnection connection, string name)
{
string query = string.Format("SELECT definition FROM sys.sql_modules JOIN sys.objects ON sys.sql_modules.object_id = sys.objects.object_id AND type in ({1}) and name = '{0}'", name, s_ProcedureType);
string script = TryExecuteQuery(connection, query);
return new ItemCode(name, ItemType.Procedure, script);
}

protected override ItemCode GetFunctionItem(DbConnection connection, string name)
{
string query = string.Format("SELECT definition FROM sys.sql_modules JOIN sys.objects ON sys.sql_modules.object_id = sys.objects.object_id AND type in ({1}) and name = '{0}'", name, s_FunctionType);
string script = TryExecuteQuery(connection, query);
return new ItemCode(name, ItemType.Function, script);
}

protected override ItemCode GetViewItem(DbConnection connection, string name)
{
string query = string.Format("SELECT definition FROM sys.sql_modules JOIN sys.objects ON sys.sql_modules.object_id = sys.objects.object_id AND type in ({1}) and name = '{0}'", name, s_ViewType);
string script = TryExecuteQuery(connection, query);
return new ItemCode(name, ItemType.View, script);
}

protected override ItemCode GetTableItem(DbConnection connection, string name)
{
string script = null;
try {
script = SmoHelper.ScriptTable(connection, null, name);
if( string.IsNullOrEmpty(script) )
script = s_CannotGetScript;
}
catch( Exception ex ) {
script = ex.Message;
}
return new ItemCode(name, ItemType.Table, script);
}

搜索数据库

您可以在上图所示界面的左边树控件中，选择一个节点，右击，然后选择“在数据库中搜索”，此时会出现如下对话框：

在上图的对话框中，点击确定按键后，可出现下面的查找结果：
说明：匹配行就会高亮显示。

搜索数据库对象的相关代码：

[Action]
public object SearchDB(string connectionId, string dbName, string searchWord,
int wholeMatch, int caseSensitive, string searchScope, string limitCount)
{
if( string.IsNullOrEmpty(searchWord) )
throw new ArgumentNullException("searchWord");

BaseBLL instance = BaseBLL.GetInstance(connectionId);

DbOjbectType types = CompareDBHelper.GetDbOjbectTypeByFlag(searchScope);
List<ItemCode> list = instance.GetDbAllObjectScript(instance.ConnectionInfo, dbName, types);

List<SearchResultItem> result = new List<SearchResultItem>(list.Count);

int limitResultCount = 0;
int.TryParse(limitCount, out limitResultCount);

FishWebLib.StringSearcher searcher =
FishWebLib.StringSearcher.GetStringSearcher(searchWord, (wholeMatch == 1), (caseSensitive == 1));

foreach( ItemCode code in list ) {
if( limitResultCount != 0 && result.Count >= limitResultCount )
break;

if( code.SqlScript.IndexOf(searchWord, StringComparison.OrdinalIgnoreCase) >= 0 ) {
string[] lines = instance.SplitCodeToLineArray(code.SqlScript);
for( int i = 0; i < lines.Length; i++ )
if( searcher.IsMatch(lines[i]) ) {
SearchResultItem item = new SearchResultItem();
item.LineNumber = i + 1;
item.ObjectName = code.Name;
item.ObjectType = code.Type.ToString();
item.SqlScript = code.SqlScript;
result.Add(item);
break;
}
}
}

return new JsonResult(result);
}

public List<ItemCode> GetDbAllObjectScript(ConnectionInfo info, string dbName, DbOjbectType type)
{
List<ItemCode> list = new List<ItemCode>();
string connectionString = GetDbConnectionString(info, dbName);

using( DbConnection connection = CreateConnection(connectionString) ) {
connection.Open();

if( (type & DbOjbectType.Table) == DbOjbectType.Table ) {
List<string> nameList = GetDbTableNames(connection);
foreach( string name in nameList )
list.Add(GetTableItem(connection, name));
}

if( (type & DbOjbectType.Procedure) == DbOjbectType.Procedure ) {
List<string> nameList = GetDbProcedureNames(connection);
foreach( string name in nameList )
list.Add(GetProcedureItem(connection, name));
}

if( (type & DbOjbectType.Function) == DbOjbectType.Function ) {
List<string> nameList = GetDbFunctionNames(connection);
foreach( string name in nameList )
list.Add(GetFunctionItem(connection, name));
}

if( (type & DbOjbectType.View) == DbOjbectType.View ) {
List<string> nameList = GetDbViewNames(connection);
foreach( string name in nameList )
list.Add(GetViewItem(connection, name));
}
}
return list;
}

复制存储过程工具

为了演示这个功能，先需要创建一个数据库。我创建了一个数据库：TestMyTool，它没有任何数据库对象，如下图

然后，从主界面中启动【复制存储过程工具】，
接着选择：数据库连接，数据库对象，
点击【刷新列表】按键，将看到以下结果：

我们可以选择要复制的（存储过程，视图，自定义函数）对象：

最后点击【开始复制】按键，即可完成复制过程。
此时数据库TestMyTool的显示结果为：

此功能的核心部分实现代码：

[Action]
public string CopyProcedures(string srcConnId, string destConnId, string srcDB, string destDB,
string spNames, string viewNames, string funcNames)
{
BaseBLL instance1 = BaseBLL.GetInstance(srcConnId);
BaseBLL instance2 = BaseBLL.GetInstance(destConnId);
if( instance1.GetType() != instance2.GetType() )
throw new Exception("数据库的种类不一致，不能执行复制操作。");

if( srcConnId == destConnId && srcDB == destDB )
throw new Exception("无效的操作。");

List<ItemCode> procedures = instance1.GetDbAllObjectScript(instance1.ConnectionInfo, srcDB, spNames, viewNames, funcNames);
return instance2.UpdateProcedures(instance2.ConnectionInfo, destDB, procedures);
}

public List<ItemCode> GetDbAllObjectScript(ConnectionInfo info,
string dbName, string spNames, string viewNames, string funcNames)
{
List<ItemCode> list = new List<ItemCode>();
string connectionString = GetDbConnectionString(info, dbName);

using( DbConnection connection = CreateConnection(connectionString) ) {
connection.Open();

if( string.IsNullOrEmpty(spNames) == false ) {
foreach( string name in spNames.Split(new char[] { ';' }, StringSplitOptions.RemoveEmptyEntries) )
list.Add(GetProcedureItem(connection, name));
}

if( string.IsNullOrEmpty(funcNames) == false ) {
foreach( string name in funcNames.Split(new char[] { ';' }, StringSplitOptions.RemoveEmptyEntries) )
list.Add(GetFunctionItem(connection, name));
}

if( string.IsNullOrEmpty(viewNames) == false ) {
foreach( string name in viewNames.Split(new char[] { ';' }, StringSplitOptions.RemoveEmptyEntries) )
list.Add(GetViewItem(connection, name));
}
}
return list;
}

public override string UpdateProcedures(ConnectionInfo info, string dbName, List<ItemCode> list)
{
string connectionString = GetDbConnectionString(info, dbName);

using( DbConnection connection = CreateConnection(connectionString) ) {
connection.Open();
DbCommand command = connection.CreateCommand();

foreach(ItemCode item in list) {
command.CommandText = GetDeleteObjectScript(item.Name, item.Type);
command.ExecuteNonQuery();

command.CommandText = string.Format(s_CreateObjectFormat, item.SqlScript.Replace("'", "''"));
command.ExecuteNonQuery();
}
}

return string.Format("操作成功，共复制了 {0} 个对象。", list.Count);
}

数据库比较工具

为了方便后面的介绍，我将复制全部的存储过程到TestMyTool，这个过程将省略贴图。
不仅如此，我还对其中的一个存储过程做了一点修改。

然后，在程序主界面中，启动【数据库比较工具】，
接着选择：数据库连接，数据库对象，
点击【开始比较数据库】按钮后，将能看到以下比较结果。
每个数据库对象的定义中，第一个不匹配的行将以高亮行显示。

为了能让您知道不匹配行的出现位置，工具还会显示不匹配行的前后5行代码。

此功能的核心部分实现代码：

internal static class CompareDBHelper
{
public sealed class ThreadParam
{
public BaseBLL Instance;
public string DbName;
public DbOjbectType DbOjbectType;
public List<ItemCode> Result;
public Exception Exception;

public ThreadParam(BaseBLL instance, string dbName, DbOjbectType type)
{
this.Instance = instance;
this.DbName = dbName;
this.DbOjbectType = type;
this.Result = new List<ItemCode>();
}
}

private static void ThreadWorkAction(object obj)
{
ThreadParam param = (ThreadParam)obj;
try {
param.Result = param.Instance.GetDbAllObjectScript(param.Instance.ConnectionInfo, param.DbName, param.DbOjbectType);
}
catch( Exception ex ) {
param.Exception = ex;
}
}

public static DbOjbectType GetDbOjbectTypeByFlag(string flag)
{
if( string.IsNullOrEmpty(flag) )
return DbOjbectType.None;

DbOjbectType types = DbOjbectType.None;

if( flag.IndexOf('T') >= 0 )
types |= DbOjbectType.Table;
if( flag.IndexOf('V') >= 0 )
types |= DbOjbectType.View;
if( flag.IndexOf('P') >= 0 )
types |= DbOjbectType.Procedure;
if( flag.IndexOf('F') >= 0 )
types |= DbOjbectType.Function;

return types;
}

public static List<CompareResultItem> CompareDB(string srcConnId, string destConnId, string srcDB, string destDB, string flag)
{
BaseBLL instance1 = BaseBLL.GetInstance(srcConnId);
BaseBLL instance2 = BaseBLL.GetInstance(destConnId);
if( instance1.GetType() != instance2.GetType() )
throw new Exception("数据库的种类不一致，比较没有意义。");

DbOjbectType types = GetDbOjbectTypeByFlag(flag);
ThreadParam param1 = new ThreadParam(instance1, srcDB, types);
ThreadParam param2 = new ThreadParam(instance2, destDB, types);
Thread thread1 = new Thread(ThreadWorkAction);
Thread thread2 = new Thread(ThreadWorkAction);
thread1.Start(param1);
thread2.Start(param2);
thread1.Join();
thread2.Join();

if( param1.Exception != null )
throw param1.Exception;
if( param2.Exception != null )
throw param2.Exception;

List<ItemCode> list1 = param1.Result;
List<ItemCode> list2 = param2.Result;

List<CompareResultItem> result = new List<CompareResultItem>();
ItemCode dest = null;

// 按数据库对象类别分次比较。
for( int typeIndex = 0; typeIndex < 4; typeIndex++ ) {
ItemType currentType = (ItemType)typeIndex;

foreach( ItemCode item1 in list1 ) {
// 如果不是当前要比较的对象类别，则跳过。
if( item1.Type != currentType )
continue;

dest = null;
foreach( ItemCode item2 in list2 ) {
if( item1.Type == item2.Type && string.Compare(item1.Name, item2.Name, true) == 0 ) {
dest = item2;
break;
}
}

if( dest == null ) {
CompareResultItem cri = new CompareResultItem();
cri.ObjectType = item1.TypeText;
cri.ObjectName = item1.Name;
cri.LineNumber = -1;
cri.SrcLine = string.Empty;
cri.DestLine = string.Empty;
cri.Reason = "源数据库中存在，而目标数据库中不存在。";
result.Add(cri);
continue;
}
else {
if( item1.SqlScript == dest.SqlScript )
continue;

// 开始比较代码了。
CompareResultItem cri = null;
string[] lines1 = instance1.SplitCodeToLineArray(item1.SqlScript);
string[] lines2 = instance1.SplitCodeToLineArray(dest.SqlScript);

for( int i = 0; i < lines1.Length; i++ ) {
if( i >= lines2.Length ) {
// 目标对象的代码行数比较少
cri = new CompareResultItem();
cri.ObjectType = item1.TypeText;
cri.ObjectName = item1.Name;
cri.LineNumber = i + 1;
GetNearLines(lines1, lines2, i, cri);
cri.Reason = "目标对象中已没有对应行数的代码。";
result.Add(cri);
break;
}

string s1 = lines1[i].Trim();
string s2 = lines2[i].Trim();
if( string.Compare(s1, s2, true) != 0 ) {
cri = new CompareResultItem();
cri.ObjectType = item1.TypeText;
cri.ObjectName = item1.Name;
cri.LineNumber = i + 1;
GetNearLines(lines1, lines2, i, cri);
cri.Reason = "代码不一致。";
result.Add(cri);
break;
}
}

if( cri != null )
continue; // 比较下一个对象

if( lines2.Length > lines1.Length ) {
// 目标对象的代码行数比较少
cri = new CompareResultItem();
cri.ObjectType = item1.TypeText;
cri.ObjectName = item1.Name;
cri.LineNumber = lines1.Length + 1;
GetNearLines(lines1, lines2, lines1.Length, cri);
cri.Reason = "源对象中已没有对应行数的代码。";
result.Add(cri);
break;
}
}
}

foreach( ItemCode item2 in list2 ) {
// 如果不是当前要比较的对象类别，则跳过。
if( item2.Type != currentType )
continue;

dest = null;
foreach( ItemCode item1 in list1 ) {
if( item1.Type == item2.Type && string.Compare(item1.Name, item2.Name, true) == 0 ) {
dest = item2;
break;
}
}

if( dest == null ) {
CompareResultItem cri = new CompareResultItem();
cri.ObjectType = item2.TypeText;
cri.ObjectName = item2.Name;
cri.LineNumber = -2;
cri.SrcLine = string.Empty;
cri.DestLine = string.Empty;
cri.Reason = "目标数据库中存在，而源数据库中不存在。";
result.Add(cri);
continue;
}
}
}

return result;
}

private static void GetNearLines(string[] lines1, string[] lines2, int index, CompareResultItem cri)
{
int firstLine;
cri.SrcLine = GetOneNearLines(lines1, index, out firstLine);
cri.SrcFirstLine = firstLine;

cri.DestLine = GetOneNearLines(lines2, index, out firstLine);
cri.DestFirstLine = firstLine;
}

private static string GetOneNearLines(string[] lines, int index, out int firstLine)
{
firstLine = -1;
System.Text.StringBuilder sb = new System.Text.StringBuilder();

int start = index - 5;
for( int i = 0; i < 11; i++ )
if( start + i >= 0 && start + i < lines.Length ) {
if( firstLine < 0 )
firstLine = start + i + 1;
sb.AppendLine(lines[start + i]);
}

return sb.ToString();
}
}

查看表结构定义

工具可以让您轻松地查看一个表结构的定义：

也可以一次查看多个表的定义：

还可一下子得到整个数据库的所有对象的创建脚本：

此功能的核心部分实现代码：

public class AjaxDataTable
{
[Action]
public object TableDescribe(string connectionId, string dbName, string tableName)
{
if( string.IsNullOrEmpty(connectionId) || string.IsNullOrEmpty(dbName) || string.IsNullOrEmpty(tableName) )
throw new ArgumentException("connString or tableName is null.");

BaseBLL instance = BaseBLL.GetInstance(connectionId);
DataTable table = instance.GetTableFields(instance.ConnectionInfo, dbName, tableName);
return new MyMvcEx.DataTableResult(table);
}

[Action]
public object MultiTableDescribe(string connectionId, string dbName, string tableNames)
{
if( string.IsNullOrEmpty(connectionId) || string.IsNullOrEmpty(dbName) || string.IsNullOrEmpty(tableNames) )
throw new ArgumentException("connString or tableName is null.");

BaseBLL instance = BaseBLL.GetInstance(connectionId);
DataSet ds = instance.GetTables(instance.ConnectionInfo, dbName, tableNames);
return new MyMvcEx.DataSetResult(ds);
}
}

修改运行环境

到目前为止，这个工具还只能在Visual Studio中运行，显然它与我们经常见到的【工具】有较大的差别。

如果您希望可以方便地运行这个工具，那么可以安装我的另一个小工具来快速地启动当前这个工具，那个工具的下载地址：【ASP.NET程序也能像WinForm程序一样运行】

然后，就可以在Windows资源管理器中启动这个小工具：

现在是不是很像一个桌面程序了？

您甚至也可以创建一个开始菜单项，或者一个快捷方式来启动这个小工具，具体方法可参考博客：【ASP.NET程序也能像WinForm程序一样运行】

关于此工具的补充说明

这个小工具只实现了一些简单的功能，而且主要集中在查看数据库的定义这块。
这个工具的早期版本中，有些人提到了要求实现查看数据表的功能。
在今天的版本中，我并没有实现，但我提供了实现这个功能所必要的一些基础代码。
例如，我提供了二个ActionResult （注意：前面小节的Action代码中，就使用了下面的二个实现类）：

public class DataTableResult : IActionResult
{
private DataTable _table;

public DataTableResult(DataTable table)
{
if( table == null )
throw new ArgumentNullException("table");

_table = table;
}

void IActionResult.Ouput(HttpContext context)
{
context.Response.ContentType = "text/html";
string html = DataTableHelper.TableToHtml(_table);
context.Response.Write(html);
}
}

public class DataSetResult : IActionResult
{
private DataSet _ds;

public DataSetResult(DataSet ds)
{
if( ds == null )
throw new ArgumentNullException("ds");

_ds = ds;
}

void IActionResult.Ouput(HttpContext context)
{
List<DataSetJsonItem> list = new List<DataSetJsonItem>();

for( int i = 0; i < _ds.Tables.Count; i++ ) {
DataTable table = _ds.Tables[i];
string html = DataTableHelper.TableToHtml(table);
list.Add(new DataSetJsonItem { TableName = table.TableName, Html = html });
}

JsonResult json = new JsonResult(list);
(json as IActionResult).Ouput(context);
}

public class DataSetJsonItem
{
public string TableName;
public string Html;
}
}

public static class DataTableHelper
{
public static string TableToHtml(DataTable table)
{
if( table == null )
throw new ArgumentNullException("table");

StringBuilder html = new StringBuilder();
html.AppendLine("<table cellpadding=\"2\" cellspacing=\"1\" class=\"myGridVew\"><thead><tr>");

for( int i = 0; i < table.Columns.Count; i++ )
html.AppendFormat("<th>{0}</th>", HttpUtility.HtmlEncode(table.Columns[i].ColumnName));

html.AppendLine("</tr></thead><tbody>");

object cell = null;
for( int j = 0; j < table.Rows.Count; j++ ) {
html.AppendLine("<tr>");

for( int i = 0; i < table.Columns.Count; i++ ) {
cell = table.Rows[j][i];
if( cell == null || DBNull.Value.Equals(cell) )
html.Append("<td></td>");
else
html.AppendFormat("<td>{0}</td>", HttpUtility.HtmlEncode(cell.ToString()));
}
html.AppendLine("</tr>");
}

html.AppendLine("</tbody></table>");
return html.ToString();
}
}

为了方便地在客户端将表格显示地漂亮些，我还提供了一个JS函数：

function SetGridViewColor(){
$("table.myGridVew").each(function(){
$(this).removeClass("myGridVew").addClass("GridView")
.find(">thead>tr").addClass("GridView_HeaderStyle").end()
.find(">tbody>tr")
.filter(':odd').addClass("GridView_AlternatingRowStyle").end()
.filter(':even').addClass("GridView_RowStyle");
});
}

如果您认为很有必要在这个工具中集成数据表的查看（或者查询数据）的功能，那么可以自行实现（工具是开源的）。
友情提示：使用上面的代码以及MyMVC框架，实现一个简单的查看数据是会比较容易的。

今天就写到这里，希望大家能喜欢这个小工具，以及 MyMVC框架。

点击此处下载全部代码

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

如何在IIS6,7中部署ASP.NET网站

2012-02-26T12:20:00Z

在我的第一篇博客中，我发布过一个示例项目，主要演示了我的我的AJAX框架和我的通用数据访问层。虽然在当初我认为我已考虑地比较周全了，而且还提供了足够的说明文档，但在发布后的将近一年的时间里，还是有不少人给我发邮件，问我一些关于不能运行示例的问题。在所有问题中，主要集中在IIS和SQL SERVER的配置方面。因此，我认为还是有必要再来谈一下在IIS6/7以及SQL SERVER中部署ASP.NET网站的过程了。

在上篇博客【写自己的ASP.NET MVC框架（下）】中，我又发布了一个示例项目，它也包含一个网站项目，今天的介绍过程将主要以这个示例为主。对于以前的示例所需配置的相同部分将不会重复介绍，不同点则会额外补充。

查看web.config文件

ASP.NET网站与一般的桌面程序不同，不是拷贝过来就能运行的（数据库连接除外）。要想运行它，通常需要一些配置过程。
但是，我们到底需要配置什么呢？
答案是：查看web.config

web.config通常会放在网站的根目录，这个文件中包含了一最重要的网站运行参数。比如：connectionStrings，httpHandlers，httpModules ，这些参数都是网站开发人员认为运行网站所必需的参数。因此，如果我们想将一个网站部署到IIS中，必须首先打开web.config文件，逐个确认这些重要的参数是否符合要求。

这里要补充一点的是：有些开发人员喜欢将各类参数放在appSettings配置节中，即便是数据库的连接字符串也放在appSettings中。我只能说：这是个很不好的习惯。因此，在部署这类网站时，可能还要注意一下appSettings是否包含数据库的连接字符串，这就需要人工识别了。当然了，appSettings中还可能包含一些重要目录配置，同样，也只能人工识别了。

今天要讲述的参数主要涉及到IIS和SQL SERVER，因此本文将会分开介绍它们。
而且IIS还会分为6和7.5二个版本来单独演示。
SQL SERVER则以 2005 Express版本来演示。
我演示所用的操作系统为：Windows Server 2003和Windows 7 ，它们分别附带了IIS 6和IIS 7.5

说明：通常我们在部署网站时，都应该先根据web.config定义的那些重要参数来配置网站。但为了让您能对这些参数有较深刻的印象，下面的演示中，不是先根据web.config来配置网站，而是采用【从创建一个站点后，一步一步地发现问题并解决】的方式来讲解这个过程。

在IIS中创建网站

每个ASP.NET程序都是一个网站，要想运行它们，都需要在IIS中部署它们，部署的第一步就是要在IIS创建一个网站。在IIS中创建网站的过程比较简单，因为IIS都提供向导界面来帮助我们完成这个配置过程，因此，本文打算省略那些无意义的贴图。

说明，我们先从IIS6开始。这里只要求您在IIS中创建一个网站，把它配置成网站就可以了，其它的配置我们后面再谈。
示例项目：点击此处进入 MyMVC DEMO 下载页面

网站创建好了吗？我停下来等一下吧。

我的网站配置好了，现在已经可以用浏览器访问它。

现在我们可以切换风格来试试效果，点击页面右上角的【3】试试看。

噢，怎么一开始就出错了：

看到这个提示，不要茫然。为了界面友好，我用JavaScript捕获了这个错误，但现在我们需要知道错误的原因是什么，怎么办呢？

有FireBug或者Fiddler2吗？
如果有，就打开它们吧。下图是我用FireBug看到的错误原因（需要重新执行刚才的操作）：

从FireBug中，我们可以看到，刚才的操作触发了一次请求，请求的地址是：/AjaxStyle/SetStyle.cspx
cspx是个什么扩展名呢？还是打开web.config看一下吧。

在web.config中，网站要求配置的一些httpHandlers中，第一个便是针对【cspx】扩展名的。

这里我要解释一下【cspx】这个扩展名了。在以前的示例中，我选择了【cs】这个扩展名表示一个AJAX调用，但是，后来发现很多人在IIS中部署中遇到问题了（原因后面再说）。于是，这次我换了个扩展名。然而，又有人问我：cspx, 是不是写错了？ 或许他认为应该是【aspx】才对。

这个问题我用邮件回答过多次了，今天用博客的形式再回答一次：
取什么扩展名都不重要，我只要选择没有用过的扩展名来区分是AJAX调用就可以了。我也可以取【fish】来做为AJAX请求地址的扩展名，只是担心一些人认为俗气而已。

IIS6 添加扩展名映射

回到IIS，在网站节点上，右击，从弹出的菜单中，选择【属性】，然后在弹出的对话框中，选择【主目录】选项卡，并点击【配置】按钮。此时的界面应该是这样的：

找到【ascx】这个扩展名，双击它，是不是弹出下面这个对话框？

照着图片的操作去完成：复制【可执行文件】的设置路径。然后点击【取消】关闭对话框。

此时将回到【应用程序配置】对话框，点击【添加...】按钮，

照着图片操作吧。对话框中的【可执行文件】的参数，此时已在Windows剪切板中，现在只要粘贴就可以了。

全部【确定】，关闭所有对话框，再回到浏览器，然后再试一次。

现在可以操作了吧？

先不要点击其它链接，还是来对刚才的操作做个小结吧。

在ASP.NET中，有时候我们可能会需要创建自己所需的HttpHandler来处理一些特殊的请求。
我的MyMVC框架就有这个需求：将AJAX请求与页面的请求分开来处理。
所以我们需要一些特殊格式的URL。通常选择一个没用过的扩展名会比较方便，因此我选择了 cspx
为了能告诉ASP.NET将以下格式的ULR映射到AjaxHandlerFactory

/Fish.AA.AjaxTest/Add.cspx
/Fish.BB.AjaxTest.Add.cspx
/Fish/BB/AjaxTest/Add.cspx
/AjaxDemo/GetMd5.cspx
/AjaxDemo.GetMd5.cspx

我就需要在web.config中注册这种URL模式，并且为了能最好的匹配这些URL，我可以使用下面的配置：

我们可以用Visual Studio自带的WebDev.WebServer.EXE来运行网站程序。
本来，这一切都是很完美的。
可是，IIS中并不支持这么复杂的path设置，它只能支持简单的扩展名映射。
所以，我也只好使用简单的扩展名：【.cspx】来向IIS注册。

我再来解释一下，为什么在ASP.NET中，前面那个path能够识别我上面所说的5种格式的URL？
在ASP.NET管线的处理器映射阶段，ASP.NET会将【*Ajax*/*.cspx,*Ajax*.*.cspx】转换成下面的正则表达式，再来检查每个请求的URL是否匹配。

(?:\A|(?<=/))[^/]*Ajax[^/]*/[^/]*\.cspx\z|(?:\A|(?<=/))[^/]*Ajax[^/]*\.[^/]*\.cspx\z

有兴趣的话，您也可以检验一下，这个正则表达式与前面的URL都能匹配。
从这里也可以看出ASP.NET对处理器的映射实现，是可以支持比较复杂的URL模式的。
关于处理器的映射过程可以参考我的博客【细说 HttpHandler 的映射过程】

前面解释了我为什么最终选择【.cspx】来向IIS注册处理器了。
在注册时，还有二个参数也比较重要：
1. 可执行文件：其实就是一个实现了ISAPI的模块，IIS会将匹配的请求交给它，然后由它再交给ASP.NET。这个参数的路径比较长，我们根本不需要记住它，只需要找个已有配置中，将它COPY出来就可以了。
2. 确认文件是否存在：这个参数一定不要选择。因为我们请求的URL并没有对应的文件存在。

这里要补充一点：
我以前发布的FishWebLib DEMO中，使用了【cc】这样的扩展名，可以按照上面的方法注册。
但我还使用了【cs】和【ascx】这二个扩展名。由于这二个扩展名的注册已经存在了，所以，我需要修改它们的配置：双击配置项，确保不要勾选【确认文件是否存在】即可。

IIS6 无扩展名的映射

让我们再回到前面已配置好的示例中，此时页面的显示应该是这个样子的：

点击一下页面上的链接【/mvc/Customers】试试。

不要以为我是在故意设置陷阱哦。我在设计示例程序时，根本也没想到会这样。

到这里，可能有人会想，在httpHandlers中不是还有个【path="/mvc/*"】没有配置吗？
继续按照前面的方法去配置就能解决问题了。

好吧，我再照着前面的方法再试着注册【path="/mvc/*"】试试，结果如下：

因此，前面的方法对于这类【无扩展名】的URL来说，是无效的。

对于这类无扩展名的URL，在IIS6中可以使用添加【通配符应用程序映射】的方法来解决。
回到【应用程序配置】对话框，点击【插入...】按钮，弹出下面的对话框：

按照图片来设置一下吧。然后，【确定】关闭对话框。此时的设置应该是这样的：

全部点击【确定】关闭所有对话框。

让我们再次回到示例程序，此时可以发现，什么问题都没有了。

再补充一句：如果使用这种方法，前面注册cspx的过程就不需要了。因为此时所有的请求都会交给ASP.NET，而ASP.NET会识别我在web.config中所做的配置。

目录的写入权限

为了方便MyMVC DEMO的部署过程，这次我选择了XML文件做为数据源。写入XML的时机是在ASP.NET被停止运行的时候（Application_End事件中）。

让一个在IIS中运行的网站停止运行的方法就是停止网站所使用的【应用程序池】。
可以在网站属性对话框中找到网站所使用的【应用程序池】：

再切到IIS的【应用程序池】的列表，找到前面那个【应用程序池】，右击鼠标，
从弹出的菜单中点击【属性】菜单，然后在出现的对话框中选择【标识】选项卡：

从这个图片中，我们可以知道网站以哪个Windows帐号在运行。记住这里，后面会用到。

好吧，点击【取消】关闭对话框。

补充一点：要想知道网站以什么帐号运行，还可以查看【Windows任务管理器】，找到w3wp.exe所在进程即可：

回到示例程序中，我们可以随便添加一些数据。
然后，在【应用程序池】列表中，停止网站所使用的应用程序池。再启动它。
重新刷新示例程序的页面。

发现什么了？是不是数据没有保存下来？

如果发现数据没有保存起来，可以继续阅读。

数据不能保存的原因并不是因为代码没有执行，而是因为，网站运行的帐号没有权限写数据文件。
XML是放在网站的App_Data目录中，为了检查网站是否有写入权限，可以在App_Data目录上右击，然后选择【属性】菜单，切换到【安全】选项卡：

经过前面的分析，我们已经知道网站是以【NETWORK SERVICE】帐号运行，然而，在这个目录的安全设置中，并没有允许【NETWORK SERVICE】帐号能有写入权限，所以，网站在停止运行时，是由于没有权限才导致不能保存数据的。

此时，我们可以赋予【NETWORK SERVICE】帐号对App_Data目录有写入权限。设置如下图：

好了，您可以再去重启网站所在的【应用程序池】，会发现现在数据能正常保存了。

SQL SERVER的配置

在FishWebLib DEMO中，我为了演示我的通用数据访问层而引入了SQL SERVER，因此，示例程序需要SQL SERVER的支持。

首先，还是回到web.config，来看一下示例程序需要访问什么样的数据库：

注意：示例程序需要连接的SQL SERVER服务器是：localhost\sqlexpress

我的机器上安装了三个SQL SERVER的实例：

因此，我需要以【命名实例】的方式来访问。
如果您的机器将SQL SERVER做为【默认实例】来安装，则需要修改为：localhost

在示例的压缩包中，我提供了SQL SERVER所需的数据文件：db\MyNorthwind.mdf
在运行示例前，我需要将它【附加】到SQL SERVER中。

现在需要先启动 SQL Server Management Studio ，连接SQL SERVER的实例后，
在【对象资源管理器】的树型控件中，找到【数据库】节点，右击，然后点击【附加...】菜单，
在出现的对话框中，点击【添加...】按钮，选择MyNorthwind.mdf文件，然后点击【确定】按钮。

我这边出错了。

再仔细地看一下，发现是日志文件没有找到造成的。
是的，我并没将日志文件也放在压缩包中。
好吧，在对话框中删除日志文件就可以了，再次【确定】。

还是出错：

注意了：这次的错误与前面的错误并不一样。这次是说没有目录的写入权限。

当遇到没有目录的访问权限时，我们首先要知道程序是以什么帐号在运行。
这是非常重要的。要不然，如何配置目录的访问权限呢？

判断程序以什么帐号运行最简单方法就是：打开【Windows任务管理器】，然后去找进程。
这个方法可参考前面的过程。最终我们可以发现sqlserver.exe是以【NETWORK SERVICE】帐号在运行（我的机器是这样）。
好吧，再按照前面设置App_Data目录权限的方法再设置MyNorthwind.mdf文件所在目录的访问权限。

再次尝试【附加】数据库，将能成功完成。
在我机器上，现在已经可以运行示例程序了。

说明：如果由于种种原因，不使用【Integrated Security=SSPI】的连接认证方式，还可以使用【用户名/密码】的方式，那就需要修改web.config中的连接字符串了。

小结：
1. 由于SQL SERVER的数据文件保存在Windows操作系统中，因此必须授予运行SQL SERVER进程的帐号所必需的目录访问权限。
2. 连接到SQL SERVER时，也可能会因为SQL SERVER验证连接身份而失败，那么也必须配置需要的访问权限。

到此为止，示例所需的IIS配置以及SQL SERVER的配置都介绍完了。

在IIS7中部署ASP.NET程序

前面介绍了如何在IIS6中部署一个ASP.NET网站，现来看一下在IIS7.5中如何完成这个过程。
接下来的演示将以Windows 7的IIS7.5为准。

IIS7.5相对于IIS6的改进，给我的感觉是：部署ASP.NET网站简直太容易了。

IIS7为了兼容老版本，它支持二种模式来运行ASP.NET程序：集成模式，经典模式。
所谓的经典模式，其实就是为了兼容IIS6的模式。下文将着重介绍集成模式，这样才能体现IIS改进的优势。

在IIS6中，我们需要配置扩展名的映射或者通配符映射，将请求交给一个ISAPI筛选器，然后由它再交给ASP.NET，最终由ASP.NET再将请求交给我们的httpHandlers, httpModules。我们在web.config中配置的httpHandlers, httpModules，对于IIS6来说是不可见的，所以，只能再次到IIS中配置。

从IIS7开始，IIS支持以一种称为【集成模式】的方式运行ASP.NET程序，此时，IIS能直接将请求交给ASP.NET的httpHandlers和httpModules，而且还可以直接从web.config中直接读取配置，因此，只要我们把web.config准备好，配置任务就非常简单了。

由于这个缘故，我在后来提供的示例中，在web.config中已增加对IIS7的支持。
以下就是二个示例项目所需的IIS7的配置部分。

FishWebLib DEMO只需要下面的配置就可以了：

MyMVC DEMO所需的配置如下：

以上这些配置会反映在IIS7.5的哪些地方看到呢？
请看下图：

在这个【处理器映射】列表中，前三个不正是我在web.config中的配置嘛。

前面还有一块fileExtensions的配置又是做什么的呢？
请看下图：

对于FishWebLib DEMO来说，它使用了 cs, ascx 这样的扩展名，而且这二个扩展名按照默认的配置是禁止访问的，所以在那个示例中，这段配置的用途是将这二个扩展名变成允许访问。

我在使用Windows7的IIS7.5时，还发现一个与IIS6不同的地方，它会默认为每个网站创建一个独立的应用程序池，而且运行帐号也不是NETWORK SERVICE，不过，我们可以容易地在【应用程序池】的属性中去修改它。

小结：
在IIS7.5中部署ASP.NET网站是件容易的事，前提是：事先准备好web.config中的system.webServer配置节。
然后只需要创建在IIS中创建一个网站，并指向程序目录即可。
注意：如果程序需要访问本地文件或者数据库，那么还需要设置文件系统或者数据库的访问权限，具体可参考前面相关小节。

80端口和域名

在前面的演示中，为了简单，选择了25678这个端口，那是因为80端口已被使用。这样做实际上不影响网站的运行，不过，URL看起来就不美观了。通常HTTP默认是使用80端口，如果使用这个端口，那么URL中就不会出现端口号了。为了让URL地址看起来更美观，按下来我将演示如何使用80端口。

在IIS中，为了能让一个网站程序运行在80号端口中，有2个办法：
1. 为网站程序使用其它的IP地址的80端口。
2. 为网站指定域名绑定。

我们可以在网卡的配置中新增一个IP地址（如果已经有多个IP就不用这样做了）：

然后在IIS中，为网站设置【绑定】，使用这个IP地址了。请参考下图：

除了使用新IP地址的方式外，我们还可以使用域名的方式让网站可以在80端口下面运行。
方法还是在IIS中设置网站的【绑定】操作，给网站指定一个域名即可：

最终的设置应该是下面这个样子的：

此时我们就可以使用下面二种方式来访问我的示例网站了：
http://192.168.0.222
http://www.mymvc-demo.com

不过这里又有个新问题：域名从哪里来？

答案有二个（对于演示来说）：
1. 修改 C:\Windows\System32\drivers\etc\hosts 文件，
增加一个映射条目：127.0.0.1 www.mymvc-demo.com 即可。
2. 如果您使用的是Windows Server的操作系统，也可以自己给自己分配域名，请继续阅读。

在Windows Server的操作系统中，我们可以使用DNS服务创建自己的域名，大致的过程是：
1. 创建一个反向查找区域。
2. 创建一个正向查找区域。
3. 在正向查找区域新建一个WWW的主机。
4. 在IIS中为网站设置绑定，指向新的域名。
5. 设置网卡的DNS服务器地址，指向有DNS服务的机器。
这种方式或许对于单台机器来说，比直接修改host文件要麻烦，但如果是在局域网内部使用将会非常方便。

DNS配置的相关过程如下：（向导中没有贴图的步骤可以直接确定）

现在我们就可以使用域名的方式来浏览我的示例了：

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

写自己的ASP.NET MVC框架（下）

2012-02-21T13:38:00Z

上篇博客【写自己的ASP.NET MVC框架（上）】我给大家介绍我的MVC框架对于Ajax的支持与实现原理。今天的博客将介绍我的MVC框架对UI部分的支持。

注意：由于这篇博客是基于前篇博客的，因此有些已说过的内容将会直接跳过，也不会给出提示。
所以，如果要想理解这篇博客，那么阅读上篇博客【写自己的ASP.NET MVC框架（上）】则是必要的。

MyMVC的特点

在开发MyMVC的过程中，我吸取了一些ASP.NET WebForm的使用经验，也参考了ASP.NET MVC，也接受了Martin Fowler对于MVC思想的总结。在设计过程中，我只实现了一些必要的功能，而且没有引入其它的类库与组件，因此，它非常简单，且容易使用。

我们可以这样理解MyMVC：它是一个简单，容易使用，且符合MVC思想的框架。

在MyMVC框架中，View仍然采用了WebForm中的Page，毕竟Page已经使用了十年，能经得起时间的检验，它仍然是我们可信赖的技术。另一方面，Page也是ASP.NET中默认的HTML输出技术，使用它会比较方便。

MyMVC与微软的ASP.NET MVC不同的是：
1. 不依赖于URL路由组件。
2. 不提供任何HtmlHelper
3. Controller只是一个Action的容器，没有基类的要求。
4. Action处理的请求不区分POST, GET
5. URL可以直接对应一个网站目录中的aspx页面（View）。
6. View的使用是使用路径来指定，与Controller,Action的名字无关。

说明：URL虽然可以与网站中的页面对应，但这种对应并不是必须的，也可以不对应。
而且本质上与WebFrom中的页面执行过程并不相同。
下图反映了在MyMVC中，一个页面请求的执行过程：

介绍示例项目

为了让大家对MyMVC有兴趣，也为了检验MyMVC的设计，我在开发MyMVC的过程，还专门开发一个基于MyMVC的ASP.NET网站示例项目。网站提供了三种显示风格（也就是三种View），下面以“客户管理”页面为例来展示三种View的不同：

风格１

View对应的代码如下：

<%@ Page Title="客户管理" Language="C#" MasterPageFile="MasterPage.master"
Inherits="MyPageView<CustomersPageModel>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server">
<%= HtmlExtension.RefJsFileHtml("/js/MyPage/Customers.js")%>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">

<p><a id="btnCreateItem" href="#" class="easyui-linkbutton" iconCls="icon-add">创建客户</a></p>

<table class="GridView" cellspacing="0" cellpadding="4" border="0" style="border-collapse:collapse;">
<tr align="left">
<th style="width:20px;"> </th>
<th style="width:260px;">客户名称</th>
<th style="width:80px;">联系人</th>
<th>地址</th>
<th style="width:80px;">邮编</th>
<th style="width:160px;">电话</th>
</tr>
<% foreach( Customer customer in Model.List ) { %>
<tr>
<td><a href="/AjaxCustomer/Delete.cspx?id=<%= customer.CustomerID %>&returnUrl=<%= RequestUrlEncodeRawUrl %>"
title="删除" class="easyui-linkbutton" plain="true">
<img src="/Images/delete.gif" alt="删除" /></a>
</td>
<td><a href="#" class="easyui-linkbutton" rowId="<%= customer.CustomerID %>" plain="true" iconCls="icon-open">
<%= customer.CustomerName.HtmlEncode()%></a>
</td>
<td><span name="ContactName"><%= customer.ContactName.HtmlEncode() %></span>
</td>
<td><span name="Address"><%= customer.Address.HtmlEncode() %></span>
</td>
<td><span name="PostalCode"><%= customer.PostalCode.HtmlEncode() %></span>
</td>
<td><span name="Tel"><%= customer.Tel.HtmlEncode() %></span>
</td>
</tr>
<% } %>

<%= Model.PagingInfo.PaginationBar(6)%>
</table>

<div id="divCustomerInfo" title="客户" style="padding: 8px; display: none">
<%= UcExecutor.Render("/Controls/Style1/CustomerInfo.ascx", Model.Customer)%>
</div>

</asp:Content>

风格２

View对应的代码如下：

<%@ Page Title="客户管理" Language="C#" MasterPageFile="MasterPage.master" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server">
<%= HtmlExtension.RefJsFileHtml("/js/MyPage2/Customers.js")%>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">

<table id="grid1"></table>

<div id="divCustomerInfo" title="客户" style="padding: 8px; display: none">
<%= UcExecutor.Render("/Controls/Style2/CustomerInfo.ascx", null)%>
</div>

</asp:Content>

风格３

View对应的代码如下：

<%@ Page Title="客户管理" Language="C#" MasterPageFile="MasterPage.master"
Inherits="MyPageView<CustomersPageModel>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">

<ul class="itemList">
<% foreach( Customer customer in Model.List ) { %>
<li>
<table class="GridView" cellspacing="0" cellpadding="4" border="0" style="border-collapse:collapse;">
<tr><td><%= customer.CustomerName.HtmlEncode()%></td></tr>
<tr><td><%= customer.ContactName.HtmlEncode() %></td></tr>
<tr><td><%= customer.Address.HtmlEncode() %></td></tr>
<tr><td><%= customer.PostalCode.HtmlEncode() %></td></tr>
<tr><td><%= customer.Tel.HtmlEncode() %></td></tr>
</table>
</li>
<% } %>
</ul>

<%= Model.PagingInfo.PaginationBar()%>

</asp:Content>

这是三种截然不同的风格，在服务端的代码也是完全不同的。

其中第二种风格，是采用了我上篇博客中总结的【纯AJAX网站】的风格来开发，因此在服务端页面的开发过程中，最为简单，它需要输出的HTML最少，UI部分由客户端的JS来实现。

对于第一种和第三种风格，它们的HTML结构是不同的，页面所能完成的功能也是不同的，除此之外，它们应该是比较类似的，都是从下面这个泛型类型继承而来：

Inherits="MyPageView<CustomersPageModel>"

从泛型类型继承的好处是：我可以在设计页面时，对于涉及Model的访问，都会有智能提示。比如：

由于有智能提示的支持，可以提高开发效率，并可以避免一些低级的拼写错误。

虽然前面我们可以从图片中看到访问【同一个URL地址】出现【三个不同的页面】，但它们背后的Controller却是同一个：

public class CustomerController
{
[Action]
[PageUrl(Url = "/mvc/Customers")]
[PageUrl(Url = "/mvc/Customers.html")]
[PageUrl(Url = "/mvc/CustomerList.aspx")]
[PageUrl(Url = "/Pages/Customers.aspx")]
public static object LoadModel(int? page)
{
// 说明：参数page表示分页数，方法名LoadModel其实可以【随便取】。

// 根据用户选择的界面风格，计算实现要呈现的页面路径。
string papeUrl = StyleHelper.GetTargetPageUrl("Customers.aspx");

if( StyleHelper.PageStyle == StyleHelper.StyleArray[1] )
// Style2 风格下，页面不需要绑定数据。数据由JS通过AJAX方式获取
return new PageResult(papeUrl, null);

// 为Style1 风格获取数据。
CustomerSearchInfo info = new CustomerSearchInfo();
info.SearchWord = string.Empty;
info.PageIndex = page.HasValue ? page.Value - 1 : 0;
info.PageSize = AppHelper.DefaultPageSize;

CustomersPageModel result = new CustomersPageModel();
result.PagingInfo = info;
result.List = BllFactory.GetCustomerBLL().GetList(info);

return new PageResult(papeUrl, result);
}
}

通过上面代码可以看到我用了4个[PageUrl]，这意味着其实我可以使用4种不同的URL都能访问到这三个页面，而且每一个URL都会根据当前用户所选择的风格，呈现对应的页面。

事实上，我还可以为这个Action指定更多的[PageUrl]，让它可以处理更多的URL。关于[PageUrl]的使用与设计目的，请继续往下阅读。

关于URL路由

随着 .net framewrok 3.5 的问世，微软发布了一个【ASP.NET 路由】组件，它的出现给当时的URL优化方法提供了另外一种选择，不仅如此，它还提供了一些URL重写组件没有的功能：生成URL 。

随着AP.NET MVC的出现，【ASP.NET 路由】成为此框架的直接依赖组件，我们很难有其它的选择，而且，想不用都不行。

有趣的是：【ASP.NET 路由】这个后生小子的出现，并没有很好地遵守ASP.NET制定的一些规则，其中最为明显的是：它跳过了【处理器的映射】阶段，导致ASP.NET MVC在支持Session时，很为难。直到最后ASP.NET 4.0，微软修改了Session的部分实现方式，这样ASP.NET MVC才能最终借此机会解决Session的完整支持问题。

ASP.NET 路由虽然可以生成URL，但它引入了RouteData的概念，要想支持它，需要在框架层面上做许多基础工作。

而且，我认为：
1. 并不是每个网站都需要这种技术，对于不需要URL优化的网站来说，URL路由的使用只是白白地浪费性能。
2. 另一方面，即使需要URL优化，我们还有众多的URL重写组件可供选择，这样可以不用改变现在构架。

因此，MyMVC虽然不支持URL路由，但并不表示不能实现URL优化。

在MVC思想中，Controller应该是处理请求的地方，也是最先运行的部分。然而在传统的WebForm编程模型中，aspx页面负责处理请求。因此，必须采取一种方式让最先处理请求的地方从aspx页面中转移，并能提前执行。

而且，将代码从页面移出还有另外二个好处：
1. 被移出的代码肯定是与UI部分无关的，因此，会比较容易测试。
2. 代码与UI的分享也意味着：可以根据运行条件，有选择地将结果交给不同的View来呈现。

考虑到Action可以选择将结果交给不同的View来呈现，而Session也需要支持的问题，最终我决定，在框架内部使用一个专门的HttpHandler来执行用户的Action，根据Action所要求的Session支持模式，HttpHandlerFactory创建不同的HttpHandler来支持。由于需要使用HttpHandlerFactory，所以必须在web.config中注册。

配置MyMVC框架

MyMVC在使用时，需要在web.config中简单的配置：

如果使用IIS7，则参考以下配置：

<system.webServer>
<handlers>
<add name="MvcPageHandlerFactory" verb="*" path="*.aspx"
type="MyMVC.MvcPageHandlerFactory, MyMVC" preCondition="integratedMode"/>
</handlers>
</system.webServer>

我们可以把MvcPageHandlerFactory理解成MyMVC在ASP.NET管线的入口。

注意：
1. 上面的配置代码中，选择aspx这个扩展名并不是必须的，您也可以选择喜欢的扩展名。
2. 如果不喜欢扩展名的映射，可以使用HttpModule，MyMVC中提供的方法也能替代这个过程。

映射处理器（入口）

在web.config中注册MvcPageHandlerFactory后，所有符合条件的请求将会进入MvcPageHandlerFactory。
我们来看一下MvcPageHandlerFactory的实现代码：

internal sealed class AspnetPageHandlerFactory : PageHandlerFactory { }

public sealed class MvcPageHandlerFactory : IHttpHandlerFactory
{
/// <summary>
/// 尝试根据当前请求，获取一个有效的Action，并返回ActionHandler
/// 此方法可以在HttpModule中使用，用于替代httpHandler的映射配置
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
public static IHttpHandler TryGetHandler(HttpContext context)
{
InvokeInfo vkInfo = ReflectionHelper.GetPageActionInvokeInfo(context.Request.FilePath);
if( vkInfo == null )
return null;

return ActionHandler.CreateHandler(vkInfo);
}

private AspnetPageHandlerFactory _msPageHandlerFactory;

IHttpHandler IHttpHandlerFactory.GetHandler(HttpContext context,
string requestType, string virtualPath, string physicalPath)
{
// 尝试根据请求路径获取Action
InvokeInfo vkInfo = ReflectionHelper.GetPageActionInvokeInfo(virtualPath);

// 如果没有找到合适的Action，并且请求的是一个ASPX页面，则按ASP.NET默认的方式来继续处理
if( vkInfo == null && virtualPath.EndsWith(".aspx", StringComparison.OrdinalIgnoreCase) ) {
if( _msPageHandlerFactory == null )
_msPageHandlerFactory = new AspnetPageHandlerFactory();

// 调用ASP.NET默认的Page处理器工厂来处理
return _msPageHandlerFactory.GetHandler(context, requestType, virtualPath, physicalPath);
}

return ActionHandler.CreateHandler(vkInfo);
}

void IHttpHandlerFactory.ReleaseHandler(IHttpHandler handler)
{
}
}

从代码中可以看到，MyMVC首先会根据当前的请求地址查找有没有一个Action可以处理它，如果没有，则采用ASP.NET默认的方式来处理。因此，把【*.aspx】交给MvcPageHandlerFactory是不会有问题的。

说明：创建一个空壳类型AspnetPageHandlerFactory的原因是：不能直接调用PageHandlerFactory的构造函数。

内部初始化

MyMVC在第一次处理请求时，要做一个初始化的过程，这个过程是由MvcPageHandlerFactory中的一个调用引发的：

// 尝试根据请求路径获取Action
InvokeInfo vkInfo = ReflectionHelper.GetPageActionInvokeInfo(virtualPath);

ReflectionHelper有个静态构造函数，虽然上次我已贴出它的代码，但那只是部分代码，以下才是完整的初始化代码：

internal static class ReflectionHelper
{
// 保存PageAction的字典
private static Dictionary<string, ActionDescription> s_PageActionDict;

// 保存AjaxController的列表
private static List<ControllerDescription> s_AjaxControllerList;
// 保存AjaxAction的字典
private static Hashtable s_AjaxActionTable = Hashtable.Synchronized(
new Hashtable(4096, StringComparer.OrdinalIgnoreCase));

// 用于从类型查找Action的反射标记
private static readonly BindingFlags ActionBindingFlags =
BindingFlags.Static | BindingFlags.Instance | BindingFlags.Public | BindingFlags.IgnoreCase;

static ReflectionHelper()
{
InitControllers();
}

/// <summary>
/// 加载所有的Controller
/// </summary>
private static void InitControllers()
{
s_AjaxControllerList = new List<ControllerDescription>(1024);
var pageControllerList = new List<ControllerDescription>(1024);

ICollection assemblies = BuildManager.GetReferencedAssemblies();
foreach( Assembly assembly in assemblies ) {
// 过滤以【System.】开头的程序集，加快速度
if( assembly.FullName.StartsWith("System.", StringComparison.OrdinalIgnoreCase) )
continue;

try {
foreach( Type t in assembly.GetExportedTypes() ) {
if( t.Name.StartsWith("Ajax") )
s_AjaxControllerList.Add(new ControllerDescription(t));

else if( t.Name.EndsWith("Controller") )
pageControllerList.Add(new ControllerDescription(t));
}
}
catch { }
}

// 提前加载Page Controller中的所有Action方法
s_PageActionDict = new Dictionary<string, ActionDescription>(4096, StringComparer.OrdinalIgnoreCase);

foreach( ControllerDescription controller in pageControllerList ) {
foreach( MethodInfo m in controller.ControllerType.GetMethods(ActionBindingFlags) ) {
PageUrlAttribute[] pageUrlAttrs = m.GetMyAttributes<PageUrlAttribute>();
ActionAttribute actionAttr = m.GetMyAttribute<ActionAttribute>();

if( pageUrlAttrs.Length > 0 && actionAttr != null ) {
ActionDescription actionDescription =
new ActionDescription(m, actionAttr) { PageController = controller };

foreach( PageUrlAttribute attr in pageUrlAttrs ) {
if( string.IsNullOrEmpty(attr.Url) == false )
s_PageActionDict.Add(attr.Url, actionDescription);
}
}
}
}

// 用于Ajax调用的Action信息则采用延迟加载的方式。
}

从以上代码可以看出，在初始化时，MyMVC加载了全部的PageAction ，而AjaxAction却没有采用这种方式来实现，为什么呢？请继续阅读。

从URL到Action的映射过程

前面我们看到了MyMVC的初始化过程，其实是在ReflectionHelper的构造函数中完成的。在这个初始化之后，MvcPageHandlerFactory调用ReflectionHelper.GetPageActionInvokeInfo(virtualPath)便可以得到要调用的Action的具体描述。我称这个过程为：从URL到Action的映射。

GetPageActionInvokeInfo方法的实现代码如下：

/// <summary>
/// 根据一个页面请求路径，返回内部表示的调用信息。
/// </summary>
/// <param name="url"></param>
/// <returns></returns>
public static InvokeInfo GetPageActionInvokeInfo(string url)
{
if( string.IsNullOrEmpty(url) )
throw new ArgumentNullException("url");

ActionDescription action = null;
if( s_PageActionDict.TryGetValue(url, out action) == false )
return null;

InvokeInfo vkInfo = new InvokeInfo();
vkInfo.Controller = action.PageController;
vkInfo.Action = action;

if( vkInfo.Action.MethodInfo.IsStatic == false )
vkInfo.Instance = Activator.CreateInstance(vkInfo.Controller.ControllerType);

return vkInfo;
}

在介绍这个映射过程之前，让我们再来回顾一下Action的声明代码：

通过ReflectionHelper构造函数中所完成的初始化过程，每个Action的描述会根据[PageUrl]的数量而生成多个字典条目，因此，在GetPageActionInvokeInfo的实现过程中，也只是简单的查找了这个字典而已，就可以得到所需要的调用信息，从面完成映射的过程。整个过程可以用以下图形来表示：

在上面的示例中，我使用了"/mvc/Customers"这种URL，显然它并不符合我在web.config中为MvcPageHandlerFactory注册时所指定的URL模式要求。那么，又该如何处理呢？

虽然这种URL虽然没有扩展名，但我仍然可以通过配置httpHandler的方式来解决，下面的配置就是我们需要的：

在介绍MvcPageHandlerFactory时，MyMVC提供了另一个方法TryGetHandler供外部使用。因此，在示例网站中，我还可以在Global.asax中调用这个方法来解决前面的那个问题：

protected void Application_PostResolveRequestCache(object sender, EventArgs e)
{
// 这里只是一个演示。
// 主要是将诸如：/mvc/Customers 这类请求映射到MyMVC框架的处理器

HttpApplication app = (HttpApplication)sender;
if( app.Request.FilePath.StartsWith("/mvc/") ) {
IHttpHandler myHandler = MyMVC.MvcPageHandlerFactory.TryGetHandler(app.Context);
if( myHandler != null )
app.Context.RemapHandler(myHandler);
}
}

对于切换HttpHandler的操作，我有以下建议：
1. 尽量放在HttpModule中去实现。因为可以通过修改配置来切换规则（启用或者禁止），所以会比较灵活。
2. 如果可以通过HttpHandler映射能实现的，尽量首选HttpHandler映射方式。原因：更快，更标准。

PageUrl的设计思想

在前面的示例代码中，我为一个Action添加多个[PageUrl]，来标记这个Action可以处理多个URL，因此，一个Action能处理哪些URL是通过指定[PageUrl]来实现的。

为什么要叫【PageUrl】？
我想或许有些人会有这个疑问。
下面我就来回答这个问题，也可以让大家了解我设计PageUrl的原因：
1. 我们请求一个URL通常是为了得到一个页面显示，因此可以认为一个URL最终可以表示成一个页面。
2. 我也想过使用[Url]这种名称，但感觉太短了，而且Ajax请求也有URL，那么必须显式地加以区分。
所以，我最终决定使用[PageUrl]这个名字。

在Ajax部分，我认为通常只需要完成获取数据以及处理提交数据的功能就可以了。因此，绝大多数情况下是不要需View的，而且，一个功能与一个URL对应，这样还可以简化问题。所以，在Ajax部分，我提倡在URL中直接指出要调用哪个Controller中的哪个Action。

在Page部分，事实上也需要一个Action，本来也是可以继续使用这种做法的，不过，我并没有这种做，理由如下：
1. 我们创建View其实也是创建Page，使用Page的路径不是更好吗？而且WebForm的粉丝或许会更喜欢。
2. 多URL的匹配功能。后面会有详细说明。

由于以上种种原因，我将[PageUrl]设计成与[Action]是独立关系，并且[PageUrl]可以多次指定的。

注意：
1. Url参数中指定的字符串，可以对应一个aspx页面。也可以不对应aspx页面。
2. Url参数中，不要包含QueryString，否则根本不能匹配。
3. 如果您使用URL重写组件，那么此处应该是重写后的路径。

由于我在MvcPageHandlerFactory中使用ASP.NET框架传入的virtualPath并不包含查询参数，因此，把它理解成页面路径也是非常合适的。

多URL的匹配功能

或许有些人认为多URL匹配一个Action是没有意义的，比如下面的这个Action会更符合常理：

public class CategoryController
{
[Action]
[PageUrl(Url = "/Pages/Categories.aspx")]
public object LoadModel()
{

是的，通常情况下，一个Action处理一个URL也是较为常见。
但仍然有二种情况需要这个功能。首先来看下面的示例：

[Action]
[PageUrl(Url = "/Pages/AddOrder.aspx")]
[PageUrl(Url = "/Pages/CodeExplorer.aspx")]
[PageUrl(Url = "/Pages/Default.aspx")]
[PageUrl(Url = "/Pages/Orders.aspx")]
public object TransferRequest()
{
// 这个Action要做的事较为简单，
// 将请求 "/Pages/Orders.aspx" 用实际的页面 "/Pages/StyleX/Orders.aspx" 来响应。
// 因为用户选择的风格不同，但URL地址是一样的，所以在这里切换。

// 当然这样的处理也只适合页面不需要Model的情况下。

string filePath = HttpContextHelper.RequestFilePath;
int p = filePath.LastIndexOf('/');
string pageName = filePath.Substring(p + 1);

return new PageResult(StyleHelper.GetTargetPageUrl(pageName), null /*model*/);
}

代码所涉及的4个页面在呈现时，由于并不需要数据，但为了能够实现多样式的支持，它们可以共用一个Action，因此这里只是切换一个View的路径而已。

理解上面那句话，可能还需要知道StyleHelper的实现代码：

public static class StyleHelper
{
public static readonly string STR_PageStyle = "PageStyle";
public static readonly string[] StyleArray = new string[] { "Style1", "Style2", "Style3" };

public static string PageStyle
{
get { return CookieHelper.GetCookieValue(STR_PageStyle) ?? StyleArray[1]; }
}

public static string GetTargetPageUrl(string pageName)
{
return string.Format("/Pages/{0}/" + pageName, PageStyle);
}

}

示例网站的目录结构如下图：

在示例网站中，由于三种风格的截然不同，尤其是在功能与HTML结构上就完全不同，因此根本不可能通过CSS或者SKIN的方式来解决，所以我为三种风格创建了三个目录，分别存放相应的页面文件。最终根据用户的选择（Cookie）来决定使用哪个目录下的页面来呈现。

用户设置风格的JS代码如下，

$(function(){
$("a.btnSetStyle").click(function(){
var style = $(this).attr("ps");

// 其实写cookie也可以直接使用JS去写的。
$.ajax({
url: "/AjaxStyle/SetStyle.cspx",
data: {style: style},
success: function(){
window.location = window.location;
}
});
return false;
});
});

服务端的C#代码如下：

public class AjaxStyle
{
[Action]
public void SetStyle(string style)
{
if( Array.IndexOf(StyleHelper.StyleArray, style) >= 0 ) {
HttpCookie cookie = new HttpCookie(StyleHelper.STR_PageStyle, style);
cookie.Expires = DateTime.Now.AddYears(1);
CookieHelper.AddCookie(cookie);
}
}
}

说明：CookieHelper是设计成支持单元测试的，所以不要怀疑这里的代码不符合MVC，后面会专门谈它。

所以，在这种情况下，多个URL映射到一个Action是有意义的。这是【多URL的匹配功能】的第一个用途。

解决老的URL兼容问题

在一个网站的成长过程中，一般会有重构的过程。在重构过程中，或许会删除以前的某些页面，或许调整URL格式。然而，用户也可能会收藏这个网站的链接，但由于页面重构了，老的链接可能会因此而失效，造成404错误。此时就要解决URL的兼容问题。

在ASP.NET中，我们可以在web.config配置urlMappings节点来做这样的映射转换。还有另一种方法是，创建一个HttpModule专门判断是否在请求一些老的URL，如果是，则重定向到新的页面。总之，不管使用哪种方法，都需要为每个传入请求检查URL是否是老格式的URL，这个过程会根据一个列表来逐一检查，不过，可惜的是：绝大部分请求可能都是新的URL格式，而那些兼容方案无疑会浪费很多的CPU资源。

在MyMVC中，可以简单地处理这个问题，就像下面的这个示例一样：

这个“客户管理”页面可能经过了多次重构，没关系，只要把各个版本的地址用[PageUrl]标识出来就可以了，完全不用前面所说的兼容方案，因此，在URL的兼容处理上没有任何负担，也不会影响性能。

说明：[PageUrl]的顺序并不重要，可以随意调整。

对身份认证的支持

MyMVC也支持一些基本的身份认证，可以通过在Action方法中添加[Authorize]修饰属性来指示。
AuthorizeAttribute的实现代码如下：

/// <summary>
/// 用于验证用户身份的修饰属性
/// </summary>
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
public class AuthorizeAttribute : Attribute
{
private string _user;
private string[] _users;
private string _role;
private string[] _roles;

private string[] SplitString(string value)
{
if( string.IsNullOrEmpty(value) )
return null;
else
return (from s in value.Split(',')
let u = s.Trim()
where u.Length > 0
select u).ToArray();
}

/// <summary>
/// 允许访问的用户列表，用逗号分隔。
/// </summary>
public string Users
{
get { return _user; }
set { _user = value; _users = SplitString(value); }
}

/// <summary>
/// 允许访问的角色列表，用逗号分隔。
/// </summary>
public string Roles
{
get { return _role; }
set { _role = value; _roles = SplitString(value); }
}

internal bool AuthenticateRequest(HttpContext context)
{
if( context.Request.IsAuthenticated == false )
return false;

if( _users != null &&
_users.Contains(context.User.Identity.Name, StringComparer.OrdinalIgnoreCase) == false )
return false;

if( _roles != null && _roles.Any(context.User.IsInRole) == false )
return false;

return true;
}
}

认证检查发生在调用Action之前，代码如下：

internal static void ExecuteAction(HttpContext context, InvokeInfo vkInfo)
{
if( context == null )
throw new ArgumentNullException("context");
if( vkInfo == null )
throw new ArgumentNullException("vkInfo");

// 验证请求是否允许访问（身份验证）
AuthorizeAttribute authorize = vkInfo.GetAuthorize();
if( authorize != null ) {
if( authorize.AuthenticateRequest(context) == false )
ExceptionHelper.Throw403Exception(context);
}

// 调用方法
object result = ExecuteActionInternal(context, vkInfo);

// 设置OutputCache
OutputCacheAttribute outputCache = vkInfo.GetOutputCacheSetting();
if( outputCache != null )
outputCache.SetResponseCache(context);

// 处理方法的返回结果
IActionResult executeResult = result as IActionResult;
if( executeResult != null ) {
executeResult.Ouput(context);
}
else {
if( result != null ) {
// 普通类型结果
context.Response.ContentType = "text/plain";
context.Response.Write(result.ToString());
}
}
}

下面的示例代码演示了它的用法：

[Action]
[Authorize(Users="fish")]
[PageUrl(Url = "/Pages/Demo/TestAuthorize/Fish.aspx")]
public object ShowFishPage()
{
// 仅当当前用户是 fish 时，才允许访问这个PageAction

// 注意：第一参数为null，表示使用当前地址。
return new PageResult(null, null);
}

[Action]
[Authorize]
[PageUrl(Url = "/Pages/Demo/TestAuthorize/LoginUser.aspx")]
public object ShowLoginUserPage()
{
// 仅当当前用户是已登录用户时，才允许访问这个PageAction

// 注意：第一参数为null，表示使用当前地址。
return new PageResult(null, null);
}

注意：
1. 如果一个Action没有使用[Authorize]，则表示允许任意用户访问（包括未登录用户）。
2. [Authorize]对于AjaxAction仍然有效。

View的设计方式

在MyMVC中，View采用了ASP.NET Page，不过，我并不建议使用CodeFile文件。不使用CodeFile文件，我想这是很多喜欢WebForm的人不能接受的。他们更愿意在CodeFile文件中获取数据，绑定数据，响应事件，处理用户的提交数据。也正是由于这个原因，才会让其它人认为WebForm是一种对单元测试极差的编程模型。

这里我要表达一下我的观点：代码是否可支持单元测试，这其中最主要的原因还是开发人员自身造成的，框架的选择只是起到促进或是部分限制的作用。就算让一些人使用ASP.NET MVC，他们所编写的代码未必就能支持单元测试，有些人实在太依赖于HttpContext.Current，甚至在ASP.NET MVC中还在写这种代码。

好吧，还是回到Page的设计这个话题上来。MyMVC所提倡的做法与ASP.NET MVC的做法类似，那就是直接在Page中采用内联的方式显示数据，而不是在CodeFile中绑定数据。许多人一看到ASP.NET MVC的这种内联写法，感觉又回到了ASP时代，认为是在倒退，其实这只是表面现象。表面的背后是：代码远离了UI。，也可以理解成：逻辑远离了UI。这也是正是ASP.NET MVC一直所提倡的：分离关注点。在新的开发理念中，原来的Page分解成View和Controller，在实现它们时，只关注自身那一部分就可以了，因此，如果单看Page时，可能是会有前面所说的那种感觉。另一方面，由于代码远离了UI，或许可以有更多的机会重构它们，使它们的重用性更高。

下面还是来回顾一下MyMVC中Page的代码：

<%@ Page Title="客户管理" Language="C#" MasterPageFile="MasterPage.master"
Inherits="MyPageView<CustomersPageModel>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">

<ul class="itemList">
<% foreach( Customer customer in Model.List ) { %>
<li>
<table class="GridView" cellspacing="0" cellpadding="4" border="0" style="border-collapse:collapse;">
<tr><td><%= customer.CustomerName.HtmlEncode()%></td></tr>
<tr><td><%= customer.ContactName.HtmlEncode() %></td></tr>
<tr><td><%= customer.Address.HtmlEncode() %></td></tr>
<tr><td><%= customer.PostalCode.HtmlEncode() %></td></tr>
<tr><td><%= customer.Tel.HtmlEncode() %></td></tr>
</table>
</li>
<% } %>
</ul>

<%= Model.PagingInfo.PaginationBar()%>

</asp:Content>

此时，对于呈现所需的数据可以直接从Model对象中获取，但要求在Page指令中指出Model的类型，这样还可以有智能提示的优点。如果页面需要显示数据，请务必从MyPageView<>继承，它的实现代码如下：

/// <summary>
/// 页面视图的基类
/// </summary>
/// <typeparam name="TModel">传递给页面呈现时所需的数据实体对象类型</typeparam>
public class MyPageView<TModel> : MyBasePage
{

/// <summary>
/// 用于页面呈现时所需的数据实体对象
/// </summary>
public TModel Model { get; set; }

}

其实也就是一个简单的类型，包含了Model这个属性而已。至于MyBasePage的实现代码，我们可以忽略它，它是直接从System.Web.UI.Page继承的。

再来一段用户控件的代码：

<%@ Control Language="C#" Inherits="MyUserControlView<Customer>" %>

<table cellpadding="4" border="0px">
<tr><td style="width: 80px">客户名称</td><td>
<input name="CustomerName" type="text" maxlength="50" id="txtCustomerName"
class="myTextbox w400" value="<%= Model.CustomerName.HtmlEncode() %>" />
</td></tr>
<tr><td>联系人</td><td>
<input name="ContactName" type="text" maxlength="50" id="txtContactName"
class="myTextbox w400" value="<%= Model.ContactName.HtmlEncode() %>" />
</td></tr>
<tr><td>地址</td><td>
<input name="Address" type="text" maxlength="50" id="txtAddress"
class="myTextbox w400" value="<%= Model.Address.HtmlEncode() %>" />
</td></tr>

<tr><td>邮编</td><td>
<input name="PostalCode" type="text" maxlength="10" id="txtPostalCode"
class="myTextbox w400" value="<%= Model.PostalCode.HtmlEncode() %>" />
</td></tr>
<tr><td>电话</td><td>
<input name="Tel" type="text" maxlength="50" id="txtTel"
class="myTextbox w400" value="<%= Model.Tel.HtmlEncode() %>" />
</td></tr>
</table>

基本上，与Page的开发方式差不多，只是基类换成了MyUserControlView<>而已。

在这里我认为要补充一点的是：
与ASP.NET MVC不同，MyMVC不提供任何HtmlHelper。
我认为HtmlHelper与MVC思想完全没有关系，因此不提供这些方法。
另一方面，很多人希望更好地控制HTML代码，因此就更没必要提供这些方法了。
如果您认为需要一些必要的HtmlHelper方法，那么可以实现自己喜欢的HtmlHelper类库。

最后我想说的是：页面继承泛型类，还需要一些额外的处理。比如下面的代码：

Inherits="MyPageView<CustomersPageModel>"

要让这种设置能够通过编译，需要在web.config中做如下配置：

ViewTypeParserFilter的实现代码较长，我就不在此贴出了，可以从本文结尾处下载。

Controller,Action的设计方式

在MyMVC中，Action分为二种：AjaxAction和PageAction。
PageAction与AjaxActioin在方法的定义上并没有什么差异，只要是个public方法就可以了。
不过，PageAction与AjaxAction不同点在于：
1. Controller的容器名称不同，PageAction要求Controller的名字必须以Controller结尾。
2. 必须有一个有效的[PageUrl]的修饰属性指出可以处理的URL
3. Action的名字与URL无关，可以随意取名。

在MyMVC中，2种Action还有另一特点是：不区分GET,POST 。
原因是：我喜欢用JQuery，用它实现客户端的Ajax时，GET, POST，只是一个参数的差别而已。另一方面，对于HTML表单来说，GET, POST也只是一个参数的差别，大部分表单也可以通过GET方式来提交，只要您愿意。所以，我想，既然客户端可以这样灵活地切换，服务端也就没有必要再去做那样限制。或许有些人认为区分二者会更安全，但我认为它们对安全性基本上不构成影响。反而，如果服务端忽略它们，只会让客户端更容易调用。

还有一种情况下可能需要区分二者：请求与提交是同一个地址。
这应该可以算得上是我在上篇总结的【以服务端为中心的网站】的开发方式。
事实上，在使用MyMVC的项目中，<form>标签应该需要手写，可能更多的时候会提交到另一个地址，
因为，我更建议使用Ajax方式提交数据。
所以，最终我决定：MyMVC的Action不区分GET, POST.

在设计MyMVC时，我一直没有忘记将View和Controller的分离，而且对于Controller，只有名字上的约束，Action的约束也较少，因此，我们在实现Action时，完全可以把它们独立到【类库项目】中，
就像示例项目这样：

这样做的好处是：测试Actioin会更容易。
此时网站可能只是一堆aspx，js, css文件。我一直期待能将aspx也交给美工去维护，这样设计但愿能让可能性更大一些。

输出HTML的方式

MyMVC提供二种方式在Action中返回HTML，分别是返回PageResult或者UcResult，表示需要呈现一个页面或者一个用户控件。当在Action返回这二种结果时，Action的部分就执行完毕了。剩下的处理是在MyMVC框架中进行的，MyMVC框架会对这二种结果，以IActionResult接口的方式调用Ouput方法输出结果给客户端。
PageResult和UcResult的实现代码如下：

public interface IActionResult
{
void Ouput(HttpContext context);
}

/// <summary>
/// 表示一个用户控件结果（用户控件将由框架执行）
/// </summary>
public sealed class UcResult : IActionResult
{
public string VirtualPath { get; private set; }
public object Model { get; private set; }

public UcResult(string virtualPath, object model)
{
if( string.IsNullOrEmpty(virtualPath) )
throw new ArgumentNullException("virtualPath");

this.VirtualPath = virtualPath;
this.Model = model;
}

void IActionResult.Ouput(HttpContext context)
{
context.Response.ContentType = "text/html";
string html = UcExecutor.Render(VirtualPath, Model);
context.Response.Write(html);
}

}

/// <summary>
/// 表示一个页面结果（页面将由框架执行）
/// </summary>
public sealed class PageResult : IActionResult
{
public string VirtualPath { get; private set; }
public object Model { get; private set; }

public PageResult(string virtualPath, object model)
{
this.VirtualPath = virtualPath;
this.Model = model;
}

void IActionResult.Ouput(HttpContext context)
{
if( string.IsNullOrEmpty(this.VirtualPath) )
this.VirtualPath = context.Request.FilePath;

context.Response.ContentType = "text/html";
string html = PageExecutor.Render(context, VirtualPath, Model);
context.Response.Write(html);
}
}

这二个类型的使用方式是一样的，都需要提供二个参数，第一个参数表示页面或者用户控件的存放路径，第二个参数表示给页面或者用户控件所需的显示数据。比如下面这个示例：

[Action]
public object ShowCustomerPicker(string searchWord, int? page)
{
CustomerSearchInfo info = new CustomerSearchInfo();
info.SearchWord = searchWord ?? string.Empty;
info.PageIndex = page.HasValue ? page.Value - 1 : 0;
info.PageSize = AppHelper.DefaultPageSize;

CustomerPickerModel data = new CustomerPickerModel();
data.SearchInfo = info;
data.List = BllFactory.GetCustomerBLL().GetList(info);

return new UcResult("/Controls/Style1/CustomerPicker.ascx", data);
}

设计这二类结果，我的本意是：
1. UcResult给Ajax请求使用，因为有可能会要求服务端输出一段HTML
2. PageResult用于整页面的响应。

在MyMVC中，执行页面或者用户控件，需要指出页面或者用户控件的路径，而不是采用什么约定关系。
我认为约定会造成名字耦合，约定也会影响限制灵活，因此，必须明确指定（允许为null）。

PageResult多用于PageAction，而PageAction又有[PageUrl]来指示可以处理哪些URL，虽然一个PageAction可以处理多个URL，但通常情况下，还是以一个PageAction处理一个URL的情况居多。此时，MyMVC允许在返回PageResult时，第一个参数可以设置为null，表示使用当前请求地址。如果此时当前请求地址有一个aspx页面与之对应，自然就会方便很多。可以参考下面的示例：

在MyMVC框架中，PageResult最终会调用PageExecutor.Render()来获取页面的生成代码，具体过程如下：

public static class PageExecutor
{
internal static readonly Type MyPageViewOpenType = typeof(MyPageView<>);

private static void SetPageModel(IHttpHandler handler, object model)
{
if( handler == null )
return;

if( model != null ) {
Type handlerType = handler.GetType().BaseType;
Type viewType = MyPageViewOpenType.MakeGenericType(model.GetType());

// 检查类型是否匹配
if( handlerType == viewType || handlerType.IsSubclassOf(viewType) ) {
DataMember member = ReflectionHelper.GetMemberByName(viewType, "Model", true);
member.SetValue(handler, model);
}
else
throw new ArgumentException("参数model的类型与页面的参数类型不一致。");
}
}

/// <summary>
/// 用指定的页面路径以及视图数据呈现结果，最后返回生成的HTML代码。
/// 页面应从MyPageView<T>继承
/// </summary>
/// <param name="context">HttpContext对象</param>
/// <param name="pageVirtualPath">Page的虚拟路径</param>
/// <param name="model">视图数据</param>
/// <returns>生成的HTML代码</returns>
public static string Render(HttpContext context, string pageVirtualPath, object model)
{
if( context == null )
throw new ArgumentNullException("context");
if( string.IsNullOrEmpty(pageVirtualPath) )
throw new ArgumentNullException("pageVirtualPath");

Page handler = BuildManager.CreateInstanceFromVirtualPath(
pageVirtualPath, typeof(object)) as Page;
if( handler == null )
throw new InvalidOperationException(
string.Format("指定的路径 {0} 不是一个有效的页面。", pageVirtualPath));

SetPageModel(handler, model);

StringWriter output = new StringWriter();
context.Server.Execute(handler, output, false);
return output.ToString();
}

UcResult则会调用UcExecutor.Render()生成用户控件的输出代码，具体过程如下：

public static class UcExecutor
{
internal static readonly Type MyUserControlViewOpenType = typeof(MyUserControlView<>);

/// <summary>
/// 用指定的用户控件以及视图数据呈现结果，最后返回生成的HTML代码。
/// 用户控件应从MyUserControlView<T>继承
/// </summary>
/// <param name="ucVirtualPath">用户控件的虚拟路径</param>
/// <param name="model">视图数据</param>
/// <returns>生成的HTML代码</returns>
public static string Render(string ucVirtualPath, object model)
{
if( string.IsNullOrEmpty(ucVirtualPath) )
throw new ArgumentNullException("ucVirtualPath");

Page page = new Page();

Control ctl = page.LoadControl(ucVirtualPath);
if( ctl == null )
throw new InvalidOperationException(
string.Format("指定的用户控件 {0} 没有找到。", ucVirtualPath));

MyBaseUserControl myctl = ctl as MyBaseUserControl;
if( myctl != null ) {
if( model != null ) {
Type viewType = MyUserControlViewOpenType.MakeGenericType(model.GetType());
Type ctrlType = myctl.GetType();

// 检查用户控件的类型是否匹配
if( ctrlType == viewType || ctrlType.IsSubclassOf(viewType) ) {
// 给用户控件的视图数据赋值。
DataMember member = ReflectionHelper.GetMemberByName(viewType, "Model", true);
member.SetValue(myctl, model);
}
else
throw new ArgumentException("参数model的类型与用户控件的参数类型不一致。");
}
}

// 将用户控件放在Page容器中。
page.Controls.Add(ctl);

StringWriter output = new StringWriter();
HtmlTextWriter write = new HtmlTextWriter(output, string.Empty);
page.RenderControl(write);

// 用下面的方法也可以的。
//HttpContext.Current.Server.Execute(page, output, false);

return output.ToString();
}

HTML分块输出

注意哦，前面介绍的2个Render方法的可见性都是public，这样设计的想法是让框架提供对外生成HTML的能力，或许有些用户有这样的需求。另一方面，或许还有些用户打算在Action的执行过程中，将原来较大的HTML页面分块输出给客户端。BigPipe就使用了这种想法：整个请求不用等到全部数据获取成功后一次性输出，而是将页面按业务逻辑拆分，并在获取到相应的数据后，立即向客户端输出部分片段。

其实HTML分块输出在ASP.NET中并不是什么新的技术，而是在ASP.NET一出现时就已经存在了，那就是在输出的过程中不断调用Response.Flush();

由于MyMVC将生成HTML做为一种基础功能，因此在MyMVC中，只要您调用Response.Flush();便可以方便地实现分块输出。不过，为了让调用更简单，我提供了二个辅助方法来简化这个过程。

在PageExecutor类型中的ResponseWrite方法：

/// <summary>
/// 用指定的Page以及视图数据呈现结果，
/// 然后将产生的HTML代码写入HttpContext.Current.Response
/// 用户控件应从MyPageView<T>继承
/// </summary>
/// <param name="pageVirtualPath">Page的虚拟路径</param>
/// <param name="model">视图数据</param>
/// <param name="flush">是否需要在输出html后调用Response.Flush()</param>
public static void ResponseWrite(string pageVirtualPath, object model, bool flush)
{
HttpContext context = HttpContext.Current;
if( context == null )
return;

if( string.IsNullOrEmpty(context.Response.ContentType) )
context.Response.ContentType = "text/html";

string html = Render(context, pageVirtualPath, model);
context.Response.Write(html);

if( flush )
context.Response.Flush();
}

在UcExecutor类型中的ResponseWrite方法：

/// <summary>
/// 用指定的用户控件以及视图数据呈现结果，
/// 然后将产生的HTML代码写入HttpContext.Current.Response
/// 用户控件应从MyUserControlView<T>继承
/// </summary>
/// <param name="ucVirtualPath">用户控件的虚拟路径</param>
/// <param name="model">视图数据</param>
/// <param name="flush">是否需要在输出html后调用Response.Flush()</param>
public static void ResponseWrite(string ucVirtualPath, object model, bool flush)
{
HttpContext context = HttpContext.Current;
if( context == null )
return;

if( string.IsNullOrEmpty(context.Response.ContentType) )
context.Response.ContentType = "text/html";

string html = Render(ucVirtualPath, model);
context.Response.Write(html);

if( flush )
context.Response.Flush();
}

注意：由于这二个方法在内部使用了HttpContext.Current，因此如果在Action中调用它们，会造成Action不能支持单元测试。

关于单元测试的支持

提到MVC思想，我想就不得不谈单元测试了。
因为MVC的主要思想还是想把这三个字目对应的事物分开，以方便开发与测试。这里面，我认为尤其是View与Controller的分离最为重要，因为有UI的地方比较难测试，反过来，如果没有UI的东西就比较容易测试了。

不过，在ASP.NET中，影响单元测试的不仅仅只是UI元素，还有HttpContxt, HttpRequest, HttpResponse这之类的核心对象。比如：即使我们将Controller放在类库项目中实现，但在Action中还在访问QueryString，Form，甚至发起重定向的请求，你说这样的代码如何测试。

我认为判断一个方法是否可支持单元测试有一个简单的办法：写个控制台的程序去调用它，看它能否正常运行。

通常，用户的输入数据主要有三个来源：QueryString, Form, Cookie。而且前二者居多，Cookie则多用于保存用户偏好设置。因此，在MyMVC中，可以让Action不再去直接访问QueryString, Form，替代的方式是：将要读取的名字做为C#方法的参数名明确指出。这样，Actioin中的代码就远离了QueryString, Form。至于Cookie的访问，MyMVC则提供一个辅助类来支持访问：

/// <summary>
/// 读写Cookie的辅助工具类。这个类对测试环境仍然有效。
/// </summary>
public static class CookieHelper
{
[ThreadStatic]
private static HttpCookieCollection s_cookies;

private static HttpCookieCollection TestCookies
{
get
{
if( TestEnvironment.IsTestEnvironment == false )
throw new InvalidOperationException();

if( s_cookies == null ) // 测试环境不考虑线程安全问题。
s_cookies = new HttpCookieCollection();
return s_cookies;
}
}

/// <summary>
/// 从Request中获取一个Cookie对象
/// </summary>
/// <param name="key"></param>
/// <returns></returns>
public static HttpCookie GetCookie(string key)
{
if( TestEnvironment.IsTestEnvironment )
return TestCookies[key];

return HttpContext.Current.Request.Cookies[key];
}

/// <summary>
/// 从Request中获取一个Cookie对象的值，如果不存在，则返回null
/// </summary>
/// <param name="key"></param>
/// <returns></returns>
public static string GetCookieValue(string key)
{
HttpCookie cookie = GetCookie(key);
if( cookie == null )
return null;
else
return cookie.Value;
}

/// <summary>
/// 将一个Cookie对应写入到Response中
/// </summary>
/// <param name="cookie"></param>
public static void SetCookie(HttpCookie cookie)
{
if( TestEnvironment.IsTestEnvironment )
TestCookies.Set(cookie);
else
HttpContext.Current.Response.Cookies.Set(cookie);
}

/// <summary>
/// 将一个Cookie对应写入到Response中
/// </summary>
/// <param name="cookie"></param>
public static void AddCookie(HttpCookie cookie)
{
if( TestEnvironment.IsTestEnvironment )
TestCookies.Add(cookie);
else
HttpContext.Current.Response.Cookies.Add(cookie);
}

/// <summary>
/// 清除所有写入的Cookie
/// </summary>
public static void ClearCookie()
{
if( TestEnvironment.IsTestEnvironment )
TestCookies.Clear();
else
HttpContext.Current.Response.Cookies.Clear();
}

/// <summary>
/// 删除指定名称的Cookie
/// </summary>
/// <param name="key"></param>
public static void RemoveCookie(string key)
{
if( TestEnvironment.IsTestEnvironment )
TestCookies.Remove(key);
else
HttpContext.Current.Response.Cookies.Remove(key);
}

}

重定向也是常见的需求。MyMVC则是通过提供RedirectResult来支持的：

/// <summary>
/// 表示一个重定向的结果
/// </summary>
public sealed class RedirectResult : IActionResult
{
public string Url { get; private set; }

public RedirectResult(string url)
{
if( string.IsNullOrEmpty(url) )
throw new ArgumentNullException("url");
Url = url;
}

void IActionResult.Ouput(HttpContext context)
{
context.Response.Redirect(Url, true);
}
}

说明：Ouput方法由框架调用，不影响Action的单元测试。
示例代码：

[Action]
public object Delete(int id)
{
BllFactory.GetCategoryBLL().Delete(id);

return new RedirectResult("/Pages/Categories.aspx");
}

在ASP.NET项目开发过程中，还有一类需求较为常见，那就是：访问一些当前环境变量。
MyMVC则是通过以下二个类型来处理的。

public static class TestEnvironment
{
/// <summary>
/// 当前运行环境是否为测试环境（非ASP.NET环境）
/// </summary>
internal static readonly bool IsTestEnvironment = (HttpRuntime.AppDomainAppId == null);

[ThreadStatic]
private static Hashtable s_ContextInfo;

private static Hashtable ContextInfo
{
get
{
if( TestEnvironment.IsTestEnvironment == false )
throw new InvalidOperationException("只有测试代码才允许执行这个调用。");

if( s_ContextInfo == null ) // 测试环境不考虑线程安全问题。
s_ContextInfo = new Hashtable(100, StringComparer.Ordinal);
return s_ContextInfo;
}
}

public static object GetValue(string key)
{
object val = ContextInfo[key];
if( val == null )
throw new InvalidOperationException("您忘记了给测试环境赋值了。参数名：" + key);
return val;
}

public static void SetValue(string key, object val)
{
ContextInfo[key] = val;
}

public static void ClearTestEnvironmentInfo()
{
ContextInfo.Clear();
CookieHelper.ClearCookie();
}
}

/// <summary>
/// 用于访问当前请求上下文的工具类。这个类对测试环境仍然有效。
/// </summary>
public static class HttpContextHelper
{
// 为了能让代码支持测试环境
// 会判断 TestEnvironment.IsTestEnvironment
// 如果在ASP.NET环境中运行，则直接返回HttpRuntime或者HttpContext.Current中的参数值
// 如果是在测试环境中运行，则使用另一个静态变量来维护所有需要访问的状态。

// 在测试前，需要先给相应的参数赋值。
// 测试完成后可调用TestEnvironment.ClearTestEnvironmentInfo()清除临时环境。

/// <summary>
/// return HttpRuntime.AppDomainAppPath;
/// </summary>
public static string AppRootPath
{
get
{
if( TestEnvironment.IsTestEnvironment )
return TestEnvironment.GetValue("AppDomainAppPath") as string;
return HttpRuntime.AppDomainAppPath;
}
set
{
TestEnvironment.SetValue("AppDomainAppPath", value);
}
}

/// <summary>
/// return HttpContext.Current.Request.FilePath;
/// </summary>
public static string RequestFilePath
{
get
{
if( TestEnvironment.IsTestEnvironment )
return TestEnvironment.GetValue("RequestFilePath") as string;
return HttpContext.Current.Request.FilePath;
}
set
{
TestEnvironment.SetValue("RequestFilePath", value);
}
}

/// <summary>
/// return HttpContext.Current.Request.RawUrl;
/// </summary>
public static string RequestRawUrl
{
get
{
if( TestEnvironment.IsTestEnvironment )
return TestEnvironment.GetValue("RequestRawUrl") as string;
return HttpContext.Current.Request.RawUrl;
}
set
{
TestEnvironment.SetValue("RequestRawUrl", value);
}
}

/// <summary>
/// return HttpContext.Current.User.Identity.Name;
/// </summary>
public static string UserIdentityName
{
get
{
if( TestEnvironment.IsTestEnvironment )
return TestEnvironment.GetValue("UserIdentityName") as string;

if( HttpContext.Current.Request.IsAuthenticated == false )
return null;

return HttpContext.Current.User.Identity.Name;
}
set
{
TestEnvironment.SetValue("UserIdentityName", value);
}
}

// 如果还需要访问更多的HttpContext信息，也可以采用下面的方法。请自行完成。

//public static HttpContextBase Current
//{
// get { }
// set { }
//}
}

注意HttpContextHelper这个类，我将平时访问的一些与请求或者与ASP.NET运行环境相关的属性全部封装在这里了。如果不够，还可以继续添加。有了这些代码，我就可以简单在控制台程序中调用它们（您也可以移到单元测试项目中）：

class Program
{
static void Main(string[] args)
{
InitDB();

Test_AjaxStyle_SetStyle();
Test_AjaxCustomer_GetById();
Test_TestEnvironment();

Console.ReadLine();
}

static void InitDB()
{
string xmlPath = "..\\..\\DemoWebSite1\\App_Data\\MyNorthwindDataBase.xml";
WebSiteDB.LoadDbFromXml(xmlPath);
}

static void Test_AjaxStyle_SetStyle()
{
AjaxStyle ajax = new AjaxStyle();
ajax.SetStyle(StyleHelper.StyleArray[0]);

if( CookieHelper.GetCookieValue(StyleHelper.STR_PageStyle) == StyleHelper.StyleArray[0] )
Console.WriteLine("AjaxStyle.SetStyle(\"{0}\") OK", StyleHelper.StyleArray[0]);
else
Console.WriteLine("AjaxStyle.SetStyle(\"{0}\") faild.", StyleHelper.StyleArray[0]);

CookieHelper.ClearCookie();

ajax.SetStyle("abc"); // 一个无效的值。
if( CookieHelper.GetCookieValue(StyleHelper.STR_PageStyle) == null )
Console.WriteLine("AjaxStyle.SetStyle(\"abc\") OK");
else
Console.WriteLine("AjaxStyle.SetStyle(\"abc\") faild.");
}

static void Test_AjaxCustomer_GetById()
{
AjaxCustomer ajax = new AjaxCustomer();
object result = ajax.GetById(1);
if( result is JsonResult )
Console.WriteLine("AjaxCustomer.GetById(1) OK");
else
Console.WriteLine("AjaxCustomer.GetById(1) faild");
}

static void Test_TestEnvironment()
{
TestEnvironment.SetValue("key1", 123);
TestEnvironment.SetValue("key2", "abc");

if( (int)TestEnvironment.GetValue("key1") == 123 )
Console.WriteLine("TestEnvironment.SetValue(123) OK.");

if( (string)TestEnvironment.GetValue("key2") == "abc" )
Console.WriteLine("TestEnvironment.SetValue(\"abc\") OK.");
}

用过ASP.NET MVC的人可能会问我：
为什么不使用System.Web.Abstractions定义的那些类型，那样不是更容易支持单元测试吗？
是啊，我也知道那种做法的好处。但那样做的工作量也会更大。
根据目前的MyMVC设计方式，如果要引入HttpContextBase, HttpRequestBase, HttpResponseBase这类对象，就需要设计Controller基类，并且创建Controller的过程也会比目前复杂，或者要把ASP.NET MVC那套创建Controller的过程搬过来，否则仍然会不完整。然而，我还是打算自己再设计另一种简单的方法尽可能地去解决这个问题。上面的方法就是我的设计，虽然不够完整，却是简单有效的，而且测试代码也会简单很多。另一方面，我不提供Controller基类，但可以设计诸如HttpContextHelper.Current这样的访问方式，最终的结果仍然是可以支持单元测试的，况且HttpContextHelper.Current这种用法也不会让人难以适应。不提供还有另外的好处：允许设计自己的基类。

还有一点要补充的是：MyMVC框架内部也没有使用System.Web.Abstractions，是的，我知道。
这也只能说：框架的代码不能进行单元测试而已。 但不影响用户的Action代码的单元测试。
再说框架中的代码有些也很难做单元测试，毕竟太依赖于ASP.NET，而且我没那么多的空闲时间以及驱动力。

MyMVC还有一个没有支持的是文件的上传与下载。
这里我来说说对于这块功能访如何去实现：
1. 可以直接访问HttpContext.Current ，并忽略这些代码的单元测试能力。
2. 自行实现我前面没有实现的HttpContextHelper.Current 。
是的，我的确没有完成这个功能，而把它留给了用户，抱歉。

关于框架代码与示例代码

在本文的未尾，我提供了MyMVC框架的代码，以及全部示例代码。

以前我也提供过我的老版本框架的演示示例，我认为我已经考虑地相当周到了：
1. 没有IIS，没有VS，一样可以运行我的DEMO，因为我把FishAspnetLoader放进去了，调用的BAT文件也准备好了。
2. SQL SERVER如果支持【用户实例】模式，部署会容易。
3. 在数据方面，我不但提供了mdf文件，还提供了sql脚本。
4. 还准备了一些说明文件。

然而，事实却没有我想像那么好，还是有很多人给我发邮件，问我示例为什么不能运行。
不能运行的环境也是让我完全没有想到的：
1. 有人把它部署到了IIS6，扩展名的映射遇到问题。
2. 有人把它部署到了IIS7，可我没有提供对IIS7的配置！
3. 有人没有安装SQL SERVER。这个只能是没有办法了！
4. 有人不能完成示例程序所需的SQL SERVER配置。
5. 有人用VS2010打开项目并升级了.net版本，遇到一些说不清楚的问题。

吸取前面的教训后，这次我的示例采用XML文件做为数据源，而且增加了IIS7的配置。
不过，有一点我不能替您设置的是XML文件的写入权限。
如果数据不能保存，请检查目录的写入权限，此时程序没有任何提示。

再补充二点：
1. 如果您使用VS2010打开示例项目，请不要选择升级.net版本，不要盲目点击确定。
2. 如果在IIS中部署示例网站遇到问题，那么建议使用VS运行示例网站。

如果您还有配置ASP.NET应用程序的问题，那么请关注我的后续博客。
下篇博客我打算谈一下在部署ASP.NET网站时，IIS6/7 以及SQL SERVER中必须知道的一些设置。

点击此处下载示例代码

注意：本文所介绍的框架还提供另外一个工具做为演示示例，
点击后面链接即可阅读。【用ASP.NET写个SQLSERVER的小工具】

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

写自己的ASP.NET MVC框架（上）

2012-02-12T14:13:00Z

写了几篇细说之后，今天打算换换口味，还是来写代码吧。所以，这次博客将以实际的代码来展示在ASP.NET平台上开发自己的框架，我希望也能让您发现这并不是件难事。

我在前面的博客【用Asp.net写自己的服务框架】中，发布了一个用ASP.NET写的服务框架，那个框架我目前仍在使用中。近来，由于时常也会有人问我一些关于ASP.NET MVC的话题，因此，就想再写个自己的MVC框架出来，一方面可以留给自己使用，另外也可以谈谈MVC，尤其可以展示一下在ASP.NET下写框架的乐趣。

我之所以将写框架看成是件有乐趣的事，是因为：在写框架的过程中会接触许多的技术细节。
比如：
1. 为了支持Session需要了解管线过程以及支持Session工作的原理。
2. 在HttpHandler的映射过程中，HttpHandlerFactory的使用会让设计很灵活。
3. 反射可以让我们轻松地根据一个URL去寻找匹配的Action以及为Action准备传入参数。
4. 为了便于测试Action，如何有效的封装框架的功能（这里有许多ASP.NET的技术细节）。
5. 如何设计让框架更灵活更强大。

在开始今天的博客之前，我想有必要说说我的框架的规模：
如果说ASP.NET WebForm是个复杂框架，ASP.NET MVC是个轻量级框架的话，那么，我的MVC框架将只是个微量级的框架。
但这个微量级的框架却可以提供许多实用的功能（因为我没有引入一些与MVC无关的东西），而且完全遵守MVC的思想而设计。
由于我的框架规模实在太小，因此，有些地方的确是不够完善，但我认为在大多数情况下是够用的。

ASP.NET程序的几种开发方式

时常见到有人在问：到底选择WebForm还是MVC ？
其实我认为最好是二个都选吧。然后，你去发现它们的优点与缺点，最后，当你觉得它们都不爽时，还是写自己的框架吧。

我来说说我这样选择的理由：任何东西都有它们的优点，这很正常，所以二个都选就能发现更多的优点，发现优点的过程其实也是自己进步的过程。当然它们也有缺点，发现那些缺点，你自然会想办法去避开，其实这也是个进步的过程。因此，在你吸收优点以及避开缺点的过程中，会感觉它们不再完美（因为自己在进步），再到后来，你会怎么选择，我就不知道了，那就是你自己的事了。而我选择了另一条路：写自己的ASP.NET MVC框架。

在比较各类框架之前，我想有必要先来总结一下：现在能用ASP.NET开发哪些类型的网站？由于ASP.NET与WCF这类纯服务性质的框架不同，我们主要还是用它来开发一些可与用户交互的界面程序。因此，今天的分类将重要讨论这些界面（UI）的开发方式。

我认为目前的ASP.NET能支持开发三种类型的网站：
1. 以服务端为中心的网站：所有页面的生成以及交互的逻辑全部服务端来完成，服务端甚至能生成必要的JS代码。
2. 门户类网站：服务端只负责页面的第一次呈现，用户的交互以及表单的提交全部采用AJAX的方式完成。
3. 纯AJAX网站：服务端基本上不参与UI的处理，只负责处理数据，UI在客户端由JavaScript来生成并控制提交。

【以服务端为中心的网站】，这类网站有个非常明显的特点，至少在开发上表现地非常明显：服务端要做的事情很多，HTML的生成, 简单的JS交互，客户端验证，等等，全由服务端来处理。在开发这类网站时，由于工作全在服务端，因此如果我们使用ASP.NET开发，自然地，所有的任务都将由aspx, C#这类技术来实现，采用这种方式开发出来的网站，页面与用户的交互性通常不会很友好，比如：提交数据时经常需要整页刷新。

【门户类网站】，这类网站与之前的【以服务端为中心的网站】有个重要的差别：页面只是呈现数据，表单的提交全采用AJAX方式了。这样做的好处能将显示逻辑与数据更新逻辑有效的分离，不必纠缠在一起（可认为是二个通道），在这种开发模式下，由于页面只负责数据的显示，因此，只要能将业务逻辑尽可能地与UI分离，项目在维护上会容易很多，采用这种方式开发的网站，页面与用户交互的友好性会好很多，而且也不会影响SEO，因此被较多的门户网站采用。

【纯AJAX网站】，在这类网站中，服务端由于不参与UI处理，网站可以只是些静态的HTML文件，而且在设计页面时，只要留下一些占位符就可以了，UI元素全部由JS来生成。这类网站的客户端通常会选择一个JS的UI框架来支持。这类界面相对于前二种来说，会更漂亮，用户的操作体验也会更友好。但由于页面主要由JS来生成，对SEO的支持较差，因此，特别适合一些后台类的网站项目。

在前面所列出的三种开发方式中，前二种由于界面部分由服务端来实现，因此选择一个合适的框架，会对开发工作有着非常重要的影响（尤其是第一种）。但是，如果选择第三种方式，那么选择 WebForm 还是 MVC 真的都是浮云了，甚至还可以使用其它的服务框架来支持AJAX的调用。

喜欢微软的MVC框架的一些人，通常会列举一些WebForm中较为低级的缺点，从而把ASP.NET MVC框架说的很完美，而且是非它不可。这里，我不想谈论它们的优点与缺点，因为我前面已经说过了，在我看来，它们都有优点也同时有各自的缺点。今天，我只想先暂且忘记它们，来实现自己的框架。

开始吧，看看我的作品。

介绍我的MVC框架

我比较喜欢ASP.NET这个平台，因为它们扩展性实在太好了，在它上面，我可以容易地实现自己所需的东西，包括开发自己所需要的WEB框架。通过微软的ASP.NET MVC框架，也让我认识到MVC思想的优点，因此，我的WEB框架也将采用MVC思想来开发，因此，我把自己的这个框架称为【我的MVC框架：MyMVC】。今天的博客也将向您展示这个框架，同时我也会与大家一起分享我在开发框架过程中所使用到的一些技术（或者称为实现方式）。

为了让大家对我的MVC框架有个感性的认识，我准备了一个示例网站，网站提供二种完全不同的风格，分别采用【门户类网站】和【纯AJAX网站】的方式来开发。在示例网站的首页，程序会让您选择喜欢的界面风格来继续后面的操作，当然，您也可以随时在右上角切换风格。

我的MVC框架设计架构

在我的框架中，【页面请求】与【AJAX请求】是分开来实现的。

因为我前面以对开发方式做过分类，在开发【纯AJAX网站】时，那么就几乎没有页面请求了（或许有，但可以忽略），此时在服务端全是AJAX服务（我喜欢将AJAX的服务端实现称为服务）。
我将AJAX请求分开来处理是因为：我做的网站中，AJAX的使用非常多，数量都会超过页面请求，而且有时甚至没有ASPX页面，全是AJAX调用，所以我更看重AJAX。

二种请求（我称为通道）大致是这样的处理过程：

说明：示意图中并没有直观地反映出【页面请求】与【AJAX请求】在处理过程中的差别，但这个差别是存在的，差别主要在于从URL到Action的映射过程，后面会有详细地介绍。

以下示意图表示了【我的MVC框架】在处理一个请求时的具体过程：

今天的博客内容将主要介绍这个框架如何实现AJAX请求处理，页面请求的实现过程将在后续的博客中介绍。

回忆以往AJAX的实现方式

我的MVC框架对AJAX的支持来源于我对代码不断重构的过程，为了更好地了解我的MVC框架，我认为有必要先来回忆一下以往是如何（在服务端）实现AJAX的。

在ASP.NET中有一种比较原始的实现Ajax的方式，那就是创建一个ashx，就像下面的代码：

<%@ WebHandler Language="C#" Class="Handler1" %>
using System;
using System.Web;

public class Handler1 : IHttpHandler {

public void ProcssRequest (HttpContext context) {
// 【1】. 从context.Request中读取输入参数
string param1 = context.Request.QueryString["param1"];
string param2 = context.Request.QueryString["param2"];

// 【2】. 根据上面所获取的参数，调用服务层或者BLL层获取结果
// var result = CallXxxxMethod(param1, param2);

// 【3】. 将结果写入context.Response
context.Response.ContentType = "text/plain";
context.Response.Write(" result ...... ");
}

public bool IsReusable { get { return false; } }
}

当然了，也有人会选择创建一个空的aspx去代替ashx，而且使用aspx还可以只输出一个HTML片段。

在这种原始的方式下，整个处理过程可以大致分为注释中所标注的三个阶段。如果使用这种方式去做服务端的AJAX开发，当AJAX的数量到达一定规模后，可以发现：大量的代码是类似。我之所以称为【类似】，是因为它们却实有差别，差别在于：参数的名字不同，参数的类型不同，参数的个数不同，要调用的方法以及返回值不同。

说实话，这种机械代码我也写过。
不过，当我发现时这个现象时，我就开始想办法去解决这个问题，因为我非常不喜欢写这类重复性质的代码。
在重构过程中，也逐渐形成了我自己的AJAX服务端框架。
后来我把它写到我的第一篇博客中了：【晒晒我的Ajax服务端框架】

在AJAX的发展过程中，微软曾经推出过ASP.NET AJAX框架，它可以在服务端生成一些JS的代理类，让客户端的JS方便地调用服务端的方法。虽然那个框架设计地很巧妙，并且与WebForm配合地很完美，只可惜那个框架不够流行。后来的WCF通过一些配置也可以让JS去调用，不过，喜欢的人也不多，可能还是因为配置麻烦的缘故吧。当后来微软推出了ASP.NET MVC框架时，一些人开始惊呼：AJAX非ASP.NET MVC框架不可。因为ASP.NET MVC框架可以很容易让JS去调用一个C#方法，从此以后，再也不用去【读参数，调用方法，写输出】这些繁琐的事情了，而且没有WCF那么复杂的配置。的确，他们没有解决的问题，ASP.NET MVC框架很好地解决了。

今天的博客，我将向大家介绍我的AJAX解决方案，它同样可以很好的解决上面的那些繁琐的过程。

MyMVC中实现AJAX的方式

在我的框架中，服务端可以很容易地将一个C#方法公开给客户端的JavaScript来访问，比如下面这个C#方法：

public class AjaxOrder
{
[Action]
public void AddOrder(OrderSubmitForm form)
{
Order order = form.ConvertToOrderItem();
BllFactory.GetOrderBLL().AddOrder(order);
}

那么客户端就可以通过这个URL地址来调用那个方法："/AjaxOrder/AddOrder.cspx" ，
URL中的一些名称与C#类名以及方法的名称的对应关系，请参考下图。
至于C#方法所需的参数，你就不用担心了，框架会替您准备好，你只要访问就可以了。
说明：这个Action太简单了，连返回值也没有。后面会有返回值的示例代码，请继续阅读。

前面的示例可以用下面的图形来表示C#代码与URL的映射关系：

补充说明一下：按照MVC的标准术语，下文将这类用于处理请求的方法将称为【Action】，Action所在的类型称为Controller。不过，在我的MVC框架中，Action又分【PageAction】和【AjaxAction】。而且，在我的MVC框架中，对Controller限制极少，不会要求您继承什么类型或者实现什么接口，Controller甚至可以是个静态类。
唯独只要求：1. 包含AjaxAction的Controller必须以Ajax开头，包含PageAction的Controller必须以Controller结尾（照顾喜欢微软MVC框架的用户）。加这个限制仅仅是为了快速定位Action，并没有其它原因。2. 类型与方法的可见性为 public （同样仅仅只是为了快速定位）。
所以，在我的框架中，Controller的意义将只是一个Action的容器。

如何使用MyMVC框架中的AJAX功能

在我的MVC框架中，JS几乎可以透明地直接调用C#方法。比如我有这样一个C#方法：

public class AjaxDemo
{
[Action]
public string GetMd5(string input)
{
if( input == null )
input = string.Empty;

byte[] bb = (new MD5CryptoServiceProvider()).ComputeHash(Encoding.Default.GetBytes(input));
return BitConverter.ToString(bb).Replace("-", "").ToLower();
}
}

方法很简单，可以计算一个字符串的MD5值。下面再来看一下如何在JS中调用：

$("#btnGetMd5").click(function(){
$.ajax({
// 以下二个URL地址都是有效的。
//url: "/AjaxDemo/GetMd5.cspx",
url: "/AjaxDemo.GetMd5.cspx",
data: {input: $("#txtInput").val()},
success: function(responseText){
$("#spanReslt").text(responseText);
}
});
});

说明一下：这里我使用JQuery这个JavaScript类库来完成客户端的部分。
在JS代码中，我通过一个URL地址就可以直接访问到前面所定义的C#方法，C#方法所面的参数由$.ajax()的data参数指定。由于实在过于简单，我感觉不需要再对这个示例做更多的解释。

唯独我要提醒的是：为了安全，JS并不能调用任何一个C#方法（虽然在技术上没有任何难度）。所以，如果您允许一个C#方法公开给JS调用，那么方法必须加[Action]这个Attribute 。

在前面的示例中，方法的传入参数以及返回值的类型都比较简单，事实上，MyMVC也可以支持复杂的数据类型。例如，以下方法的签名都是有效的：

[Action]
public void Insert(Customer customer)

[Action]
public object Delete(int id, string returnUrl)

[Action]
public object ShowCustomerPicker(string searchWord, int? page)

[Action]
public object Search(OrderSearchInfo info, int? page)

[Action]
public object ShowProductPicker(int? categoryId, string searchWord, int? page)

[Action]
public object LoadModel()

有了MyMVC，就几乎上不需要再去访问QueryString，Form这些对象了。你需要什么参数，只要写在方法的签名中就可以了。参数可以是简单的数据类型，也可以是自定义的数据类型，参数的个数也没有限制。

不过，有一点我要提醒您：所有的数据来源只有二个地方：QueryString和Form，框架只读取这二个地方，而且直接访问它们的索引器。由于QueryString，Form这二个类型都是NameValueCollection，而NameValueCollection的索引器在实现上有点独特，因此请大家注意它们的返回值。关于NameValueCollection的细节描述，可以参考我的博客【细说 Request[]与Request.Params[]】，今天我就不再重谈这个细节话题了。

在读取参数时，万一出现key重复了怎么办？
框架还提供另一种解决方案，那就是您可以在C#的方法的签名中，声明NameValueCollection类型的变量，变量名可以从【Form，QueryString，Headers，ServerVariables】中选择。注意：对于后二者，框架本身也是不读取的，如果需要读取，只能使用这个方法来获取。示例代码如下：

[Action]
public string TestNameValueCollection(NameValueCollection queryString, NameValueCollection form,
NameValueCollection headers, NameValueCollection serverVariables)
{
StringBuilder sb = new StringBuilder();

foreach( string key in queryString.AllKeys )
sb.AppendFormat("queryString, {0} = {1}\r\n", key, queryString[key]);
foreach( string key in form.AllKeys )
sb.AppendFormat("form, {0} = {1}\r\n", key, form[key]);
foreach( string key in headers.AllKeys )
sb.AppendFormat("headers, {0} = {1}\r\n", key, headers[key]);
foreach( string key in serverVariables.AllKeys )
sb.AppendFormat("serverVariables, {0} = {1}\r\n", key, serverVariables[key]);
return sb.ToString();
}

代码中，我同时要求框架给出这四个集合，事实上，您可以根据实际情况来决定需要多少个参数。

注意：
1. 参数名称是大小写【不敏感】的。
2. 类型一定要求是NameValueCollection 。
3. 框架会优先读取QueryString，如果没有则会查看Form
4. 千万不要在Action中使用HttpContext.Current.Request.QueryString[]的方式读取来自客户端的参数。

关于参数，还有一种特殊的情况：我在博客【细说 Form (表单)】中曾提到过，例如，我有这样二个类型，它们的结构一样：

public class Customer
{
public string Name;
public string Tel;
}
public class Salesman
{
public string Name { get; set; }
public string Tel { get; set; }
}

如果此时我有这样一个C#方法，又该如何处理呢？

[Action]
public string TestCustomerType(Customer customer, Salesman salesman)
{
return "customer.Name = " + customer.Name + "\r\n" +
"customer.Tel = " + customer.Tel + "\r\n" +
"salesman.Name = " + salesman.Name + "\r\n" +
"salesman.Name = " + salesman.Tel;
}

上面的示例也可以理解成：一模一样的参数类型，就是要出现多次，再或者，多个不同的自定义类型中，有些成员的名称是相同的。
此时我的框架在设计时与微软的MVC框架一样，要求在HTML中对name做特殊的设置，示例代码如下：

<form action="/AjaxDemo2/TestCustomerType.cspx" method="post">
<p>客户名称: <input type="text" name="customer.Name" style="width: 300px" /></p>
<p>客户电话: <input type="text" name="customer.Tel" style="width: 300px" /></p>
<p>销售员名称: <input type="text" name="salesman.Name" style="width: 300px" /></p>
<p>销售员电话: <input type="text" name="salesman.Tel" style="width: 300px" /></p>
<p><input type="submit" value="提交" /></p>
</form>

此时要求：input标签中的name必须能够反映C#方法的参数名以及类型中所包含的数据成员名称。

注意：在MyMVC框架中，自定义的数据类型所包含的数据成员不要求是属性，字段(Field)也是完全受支持的。

配置MyMVC框架

MyMVC框架在使用前，必须配置。
在前面的示例中，"/AjaxDemo2/TestCustomerType.cspx" 这样的URL地址，按照ASP.NET的默认设置，它是不能被映射到一个有效的处理器的，那时，将出现一个404异常。因此，为了使用MyMVC中对AJAX的支持，必须做以下配置：

如果在IIS7的环境中运行，还需要以下配置：

<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".cspx"/>
<add fileExtension=".cspx" allowed="true"/>
</fileExtensions>
</requestFiltering>
</security>
<handlers>
<add name="AjaxHandlerFactory" verb="*" path="*Ajax*/*.cspx"
type="MyMVC.AjaxHandlerFactory, MyMVC" preCondition="integratedMode"/>
</handlers>
</system.webServer>

在示例代码中，我使用了【cspx】这个扩展名，如果您不喜欢，也可以选择您所喜欢的扩展名，这个不是问题。

关于配置参数中的【path】属性，请参考我的上篇博客【细说 HttpHandler 的映射过程】，这里也不再重新解释。如果没有看过的，建议还是去看一下，下面将会用到那些知识，因为它非常重要。

MyMVC框架的实现原理 - 映射处理器（入口）

前面谈到了MyMVC框架的配置，通过那个配置，相当于在ASP.NET中为MyMVC注册了一个入口点。

根据上面的配置，符合条件的请求将会被映射给AjaxHandlerFactory。既然是这样，我们来看一下这个入口点的实现代码：

internal sealed class AjaxHandlerFactory : IHttpHandlerFactory
{
public IHttpHandler GetHandler(HttpContext context,
string requestType, string virtualPath, string physicalPath)
{
// 根据请求路径，定位到要执行的Action
ControllerActionPair pair = UrlParser.ParseAjaxUrl(virtualPath);
if( pair == null )
ExceptionHelper.Throw404Exception(context);

// 获取内部表示的调用信息
InvokeInfo vkInfo = ReflectionHelper.GetAjaxInvokeInfo(pair);
if( vkInfo == null )
ExceptionHelper.Throw404Exception(context);

// 创建能够调用Action的HttpHandler
return ActionHandler.CreateHandler(vkInfo);
}

public void ReleaseHandler(IHttpHandler handler)
{
}
}

代码中，每个步骤做了什么事情，注释中有说明，不需要再重复说明。最后创建的ActionHandler的实现代码如下：

internal class ActionHandler : IHttpHandler
{
internal InvokeInfo InvokeInfo;

public void ProcessRequest(HttpContext context)
{
// 调用核心的工具类，执行Action
ActionExecutor.ExecuteAction(context, this.InvokeInfo);
}

public bool IsReusable
{
get { return false; }
}

整个入口点就是这样的。
有没人想过：为什么不直接在web.config中映射到这个ActionHandler呢？
答案在后面，请继续阅读。

MyMVC框架的实现原理 - 对Session的支持

前面有一个方法的实现我故意没有贴出，那么是ActionHandler.CreateHandler()这个静态方法。现在是时候来贴它了：

public static ActionHandler CreateHandler(InvokeInfo vkInfo)
{
SessionMode mode = vkInfo.GetSessionMode();

if( mode == SessionMode.NotSupport )
return new ActionHandler { InvokeInfo = vkInfo };
else if( mode == SessionMode.ReadOnly )
return new ReadOnlySessionActionHandler { InvokeInfo = vkInfo };
else
return new RequiresSessionActionHandler { InvokeInfo = vkInfo };
}

这段代码又涉及另外二个类型，它们的实现代码如下：

internal class RequiresSessionActionHandler : ActionHandler, IRequiresSessionState
{
}

internal class ReadOnlySessionActionHandler :
ActionHandler, IRequiresSessionState, IReadOnlySessionState
{
}

不要感到奇怪，这二个类型的确没有任何代码。

它们除了从ActionHandler继承而来，还实现了另外二个接口，那二个接口我在博客【Session，有没有必要使用它？】中已有详细的解释，不明白的朋友，可以去阅读那篇博客。

再来回答前面那个问题：为什么不直接在web.config中映射到这个ActionHandler呢？
答：如果这样配置，那么对Session的支持将只有一种模式！
在这个框架中，我采用HttpHandlerFactory就可以轻松地实现对多种Session模式的支持。
说到这里，我真的感觉上篇博客【细说 HttpHandler 的映射过程】的研究成果太有意义了，是它给【MyMVC对Session完美的支持】提供了灵感。

老实说：我是不使用Session的。
但看到以前的博客中有些人还是坚持使用Session，所以就决定在MyMVC中支持这个功能，毕竟支持Session不是件难事。

下面再来说说如何支持Session 。

[SessionMode(SessionMode.Support)]
[Action]
public int TestSessionMode(int a)
{
// 一个累加的方法，检验是否可以访问Session
// 警告：示例代码的这样做法会影响Action的单元测试。

if( System.Web.HttpContext.Current.Session == null )
throw new InvalidOperationException("Session没有开启。");

object obj = System.Web.HttpContext.Current.Session["counter"];
int counter = (obj == null ? 0 : (int)obj);
counter += a;
System.Web.HttpContext.Current.Session["counter"] = counter;
return counter;
}

在上面这段代码中，我加了一个[SessionMode]的Attribute，用它可以指定Action的Session支持模式，SessionMode是个枚举值，定义如下：

/// <summary>
/// Action所支持的Session模式
/// </summary>
public enum SessionMode
{
/// <summary>
/// 不支持
/// </summary>
NotSupport,
/// <summary>
/// 全支持
/// </summary>
Support,
/// <summary>
/// 仅支持读取
/// </summary>
ReadOnly
}

MyMVC框架支持以上三种不同的Session模式，默认是关闭的，如果需要使用，请显式指定。[SessionMode]既可以用于Controller类型，也可以用于Action 。

注意：Session的使用将会给Action的单元测试带来麻烦。

MyMVC框架的实现原理 - 对OutputCache的支持

MyMVC框架对OutputCache也有着很好的支持。下面的代码演示了如何使用OutputCache：

[OutputCache(Duration=10, VaryByParam="none")]
[Action]
public string TestOutputCache()
{
return DateTime.Now.ToString();
}

如果在浏览器中访问这个地址：http://localhost:34743/AjaxDemo/TestOutputCache.cspx
会发现结果在10秒钟内不会有改变（F5刷新），如果打开Fiddler2，会看到304的响应。

[OutputCache]所支持的属性较多，这里就不一一列出了，下面再来说说它的实现原理。

我在博客【细说 ASP.NET控制HTTP缓存】曾分析过ASP.NET Page的缓存页实现原理，其中有个小节【缓存页的服务端编程】专门分析了Page对OutputCache的实现过程，在MyMVC中，就是使用的这种方法，具体过程可以参考那篇博客。补充一句：微软的ASP.NET MVC也是这样做的，它也是借助了Page的强大功能。

MyMVC中的代码：

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false)]
public class OutputCacheAttribute : Attribute
{
private OutputCacheParameters _cacheSettings = new OutputCacheParameters();

// 略过一些属性。

internal void SetResponseCache(HttpContext context)
{
if( context == null )
throw new ArgumentNullException("context");

OutputCachedPage page = new OutputCachedPage(_cacheSettings);
page.ProcessRequest(context);
}

private sealed class OutputCachedPage : Page
{
private OutputCacheParameters _cacheSettings;

public OutputCachedPage(OutputCacheParameters cacheSettings)
{
this.ID = Guid.NewGuid().ToString();
_cacheSettings = cacheSettings;
}

protected override void FrameworkInitialize()
{
base.FrameworkInitialize();
InitOutputCache(_cacheSettings);
}
}
}

在OutputCacheAttribute类的用法中，清楚地指出适用于类型与方法，因此，这个Attribute可以用于Controller和Action 。

说明：OutputCacheAttribute与SessionModeAttribute类似，都可以用于Controller和Action，同时使用时，Action优先匹配，代码如下：

internal sealed class InvokeInfo
{
public ControllerDescription Controller;
public ActionDescription Action;
public object Instance;

public OutputCacheAttribute GetOutputCacheSetting()
{
if( this.Action != null && this.Action.OutputCache != null )
return this.Action.OutputCache;
if( this.Controller != null && this.Controller.OutputCache != null )
return this.Controller.OutputCache;
return null;
}
public SessionMode GetSessionMode()
{
if( this.Action != null && this.Action.SessionMode != null )
return this.Action.SessionMode.SessionMode;
if( this.Controller != null && this.Controller.SessionMode != null )
return this.Controller.SessionMode.SessionMode;
return SessionMode.NotSupport;
}
}

因此，框架只要选择一个时机调用SetResponseCache()方法就可以了，至于这个调用时机出现在哪里，请继续阅读。

MyMVC框架的实现原理 - 查找Action的过程

前面有张图片反映了从URL地址到Action的映射过程：

下面再来谈谈这个过程的实现。
首先，我们要先在web.config中注册MyMVC的HttpHandlerFactory，它是整个框架的入口。
在ASP.NET的管线过程中，会调用GetHandler()方法，终于我的代码有机会运行了！
框架执行的第一行代码是：

// 根据请求路径，定位到要执行的Action
ControllerActionPair pair = UrlParser.ParseAjaxUrl(virtualPath);

ControllerActionPair是我定义的一个表示Controller以及Action名字的值对类型：

public sealed class ControllerActionPair
{
public string Controller;
public string Action;
}

静态方法UrlParser.ParseAjaxUrl()就是专门用来解析URL并返回ControllerActionPair的：

internal static class UrlParser
{
// 用于匹配Ajax请求的正则表达式，
// 可以匹配的URL：/AjaxClass/method.cspx?id=2
// 注意：类名必须Ajax做为前缀
internal static readonly string AjaxUrlPattern
= @"/(?<name>(\w[\./\w]*)?(?=Ajax)\w+)[/\.](?<method>\w+)\.[a-zA-Z]+";

public static ControllerActionPair ParseAjaxUrl(string path)
{
if( string.IsNullOrEmpty(path) )
throw new ArgumentNullException("path");

Match match = Regex.Match(path, AjaxUrlPattern);
if( match.Success == false )
return null;

return new ControllerActionPair {
Controller = match.Groups["name"].Value.Replace("/", "."),
Action = match.Groups["method"].Value
};
}
}

代码很简单，核心其实就是那个正则表达式，从URL中提取Controller，Action的名字全靠它。
至于正则表达式的使用，我想这是个基本功，这里就略过了。

再来看AjaxHandlerFactory的第二个调用：

// 获取内部表示的调用信息
InvokeInfo vkInfo = ReflectionHelper.GetAjaxInvokeInfo(pair);

ReflectionHelper类是一个内部使用的工具类，专门用于反射处理，AjaxAction查找过程的相关代码如下（注意代码中的注释）：

internal static class ReflectionHelper
{

// 保存AjaxController的列表
private static List<ControllerDescription> s_AjaxControllerList;
// 保存AjaxAction的字典
private static Hashtable s_AjaxActionTable = Hashtable.Synchronized(
new Hashtable(4096, StringComparer.OrdinalIgnoreCase));

// 用于从类型查找Action的反射标记
private static readonly BindingFlags ActionBindingFlags =
BindingFlags.Static | BindingFlags.Instance | BindingFlags.Public | BindingFlags.IgnoreCase;

static ReflectionHelper()
{
InitControllers();
}

/// <summary>
/// 加载所有的Controller
/// </summary>
private static void InitControllers()
{
s_AjaxControllerList = new List<ControllerDescription>(1024);

ICollection assemblies = BuildManager.GetReferencedAssemblies();
foreach( Assembly assembly in assemblies ) {
// 过滤以【System.】开头的程序集，加快速度
if( assembly.FullName.StartsWith("System.", StringComparison.OrdinalIgnoreCase) )
continue;

try {
foreach( Type t in assembly.GetExportedTypes() ) {
if( t.Name.StartsWith("Ajax") )
s_AjaxControllerList.Add(new ControllerDescription(t));
}
}
catch { }
}

// 用于Ajax调用的Action信息则采用延迟加载的方式。
}

/// <summary>
/// 根据要调用的controller名返回对应的Controller （适用于Ajax调用）
/// </summary>
/// <param name="controller"></param>
/// <returns></returns>
private static ControllerDescription GetAjaxController(string controller)
{
if( string.IsNullOrEmpty(controller) )
throw new ArgumentNullException("controller");

// 查找类型的方式：如果有点号，则按全名来查找(包含命名空间)，否则只看名字。
// 本框架对于多个匹配条件的类型，将返回第一个匹配项。
if( controller.IndexOf('.') > 0 )
return s_AjaxControllerList.FirstOrDefault(
t => string.Compare(t.ControllerType.FullName, controller, true) == 0);
else
return s_AjaxControllerList.FirstOrDefault(
t => string.Compare(t.ControllerType.Name, controller, true) == 0);
}

/// <summary>
/// 根据要调用的方法名返回对应的 Action （适用于Ajax调用）
/// </summary>
/// <param name="controller"></param>
/// <param name="action"></param>
/// <returns></returns>
private static ActionDescription GetAjaxAction(Type controller, string action)
{
if( controller == null )
throw new ArgumentNullException("controller");
if( string.IsNullOrEmpty(action) )
throw new ArgumentNullException("action");

// 首先尝试从缓存中读取
string key = action + "@" + controller.FullName;
ActionDescription mi = (ActionDescription)s_AjaxActionTable[key];

if( mi == null ) {
// 注意：这里不考虑方法的重载。
MethodInfo method = controller.GetMethod(action, ActionBindingFlags);

if( method == null )
return null;

var attrs = (ActionAttribute[])method.GetCustomAttributes(typeof(ActionAttribute), false);
if( attrs.Length != 1 )
return null;

mi = new ActionDescription(method, attrs[0]);
s_AjaxActionTable[key] = mi;
}

return mi;
}

/// <summary>
/// 根据一个AJAX的调用信息（类名与方法名），返回内部表示的调用信息。
/// </summary>
/// <param name="pair"></param>
/// <returns></returns>
public static InvokeInfo GetAjaxInvokeInfo(ControllerActionPair pair)
{
if( pair == null )
throw new ArgumentNullException("pair");

InvokeInfo vkInfo = new InvokeInfo();

vkInfo.Controller = GetAjaxController(pair.Controller);
if( vkInfo.Controller == null )
return null;

vkInfo.Action = GetAjaxAction(vkInfo.Controller.ControllerType, pair.Action);
if( vkInfo.Action == null )
return null;

if( vkInfo.Action.MethodInfo.IsStatic == false )
vkInfo.Instance = Activator.CreateInstance(vkInfo.Controller.ControllerType);

return vkInfo;
}

上面就是AjaxAction查找相关的4段代码：
1. 在ReflectionHelper的静态构造函数中，我加载了所有AjaxController。
2. GetAjaxController方法用于根据一个Controller的名字返回Controller的类型描述。
3. GetAjaxAction方法用于根据Controller的类型以及要调用的Action的名字返回Action的描述信息。
4. GetAjaxInvokeInfo方法用于根据从AjaxHandlerFactory得到的ControllerActionPair描述转成更具体的描述信息。

代码中，Action的查找过程采用了延迟的加载模式，保存Action描述信息的集合我采用了线程安全的Hashtable

好了，上面那段代码我想说的就这些，剩下的就只些反射的使用，这也算是个基本功，而且也不是三言二语能说清楚的。因此，我打算继续谈其它的内容了。

MyMVC框架的实现原理 - 执行Action的过程

在AjaxHandlerFactory的GetHandler方法中，最后将创建一个ActionHandler，这是一个HttpHandler，它将在管线的第15个步骤中被调用（引用博客【用Asp.net写自己的服务框架】中的顺序）。

注意：AjaxHandlerFactory的GetHandler方法是在第10步中调用的，第12步就是在准备Session（非进程内模式），因此，必须在第12步前决定Session的使用方式。

所有的Action代码都是在ActionHandler中执行的：

ExecuteAction的实现过程如下：

internal static void ExecuteAction(HttpContext context, InvokeInfo vkInfo)
{
if( context == null )
throw new ArgumentNullException("context");
if( vkInfo == null )
throw new ArgumentNullException("vkInfo");

// 调用方法
object result = ExecuteActionInternal(context, vkInfo);

// 设置OutputCache
OutputCacheAttribute outputCache = vkInfo.GetOutputCacheSetting();
if( outputCache != null )
outputCache.SetResponseCache(context);

// 处理方法的返回结果
IActionResult executeResult = result as IActionResult;
if( executeResult != null ) {
executeResult.Ouput(context);
}
else {
if( result != null ) {
// 普通类型结果
context.Response.ContentType = "text/plain";
context.Response.Write(result.ToString());
}
}
}

internal static object ExecuteActionInternal(HttpContext context, InvokeInfo info)
{
// 准备要传给调用方法的参数
object[] parameters = GetActionCallParameters(context, info.Action);

// 调用方法
if( info.Action.HasReturn )
return info.Action.MethodInfo.Invoke(info.Instance, parameters);

else {
info.Action.MethodInfo.Invoke(info.Instance, parameters);
return null;
}
}

前面我不是没有说调用SetResponseCache()的时机嘛，这个时机就是在这里：执行完Action后。
设置过OutputCache后，就是处理返回值了。

前面那段代码中，还有一句重要的调用：

// 准备要传给调用方法的参数
object[] parameters = GetActionCallParameters(context, info.Action);

这个调用的意义在注释中有解释，关于这个过程的实现方式还请继续阅读。

MyMVC框架的实现原理 - 如何给方法赋值

用过反射的人都知道，调用一个方法很简单，但如何给一个【不知签名】的方法准备传入参数呢？
下面就来回答这个问题，请接着看GetActionCallParameters的实现过程：

private static object[] GetActionCallParameters(HttpContext context, ActionDescription action)
{
if( action.Parameters == null || action.Parameters.Length == 0 )
return null;

object[] parameters = new object[action.Parameters.Length];

for( int i = 0; i < action.Parameters.Length; i++ ) {
ParameterInfo p = action.Parameters[i];

if( p.IsOut )
continue;

if( p.ParameterType == typeof(NameValueCollection) ) {
if( string.Compare(p.Name, "Form", StringComparison.OrdinalIgnoreCase) == 0 )
parameters[i] = context.Request.Form;
else if( string.Compare(p.Name, "QueryString", StringComparison.OrdinalIgnoreCase) == 0 )
parameters[i] = context.Request.QueryString;
else if( string.Compare(p.Name, "Headers", StringComparison.OrdinalIgnoreCase) == 0 )
parameters[i] = context.Request.Headers;
else if( string.Compare(p.Name, "ServerVariables", StringComparison.OrdinalIgnoreCase) == 0 )
parameters[i] = context.Request.ServerVariables;
}
else{
Type paramterType = p.ParameterType.GetRealType();

// 如果参数是简单类型，则直接从HttpRequest中读取并赋值
if( paramterType.IsSimpleType() ) {
object val = ModelHelper.GetValueByKeyAndTypeFrommRequest(
context.Request, p.Name, paramterType, null);
if( val != null )
parameters[i] = val;
}
else {
// 自定义的类型。首先创建实例，然后给所有成员赋值。
// 注意：这里不支持嵌套类型的自定义类型。
object item = Activator.CreateInstance(paramterType);
ModelHelper.FillModel(context.Request, item, p.Name);
parameters[i] = item;
}
}
}

return parameters;
}

要理解这段代码还要从前面的【查找Action的过程】说起，在那个阶段，可以获取一个Action的描述，具体在框架内部表示为ActionDescription类型：

internal sealed class ActionDescription : BaseDescription
{
public ControllerDescription PageController; //为PageAction保留
public MethodInfo MethodInfo { get; private set; }
public ActionAttribute Attr { get; private set; }
public ParameterInfo[] Parameters { get; private set; }
public bool HasReturn { get; private set; }

public ActionDescription(MethodInfo m, ActionAttribute atrr) : base(m)
{
this.MethodInfo = m;
this.Attr = atrr;
this.Parameters = m.GetParameters();
this.HasReturn = m.ReturnType != ReflectionHelper.VoidType;
}
}

在构造函数的第三行代码中，我就可以得到这个方法的所有参数情况。
然后，我在就可以在GetActionCallParameters方法中，循环每个参数的定义，为它们赋值。
这段代码也解释了前面所说的只支持4种NameValueCollection集合的原因。

注意了，我在获取每个参数的类型时，是使用了下面的语句：

Type paramterType = p.ParameterType.GetRealType();

实际上，ParameterType就已经反映了参数的类型，为什么不直接使用它呢？
答：因为【可空泛型】的原因。这个类型我们需要特殊的处理。
例如：如果某个参数是这样声明的： int? id
那么，即使在QueryString中包含id这样一个参数，我也不能直接转成 int? 使用这种类型，必须得到它的【实际类型】。
GetRealType()是个扩展方法，它就专门完成这个功能：

/// <summary>
/// 得到一个实际的类型（排除Nullable类型的影响）。比如：int? 最后将得到int
/// </summary>
/// <param name="type"></param>
/// <returns></returns>
public static Type GetRealType(this Type type)
{
if( type.IsGenericType )
return Nullable.GetUnderlyingType(type) ?? type;
else
return type;
}

如果某个参数的类型是一个自定义的类型，框架会先创建实例（调用无参的构造函数），然后给它的Property, Field赋值。

注意了：自定义的类型，一定要提供一个无参的构造函数。

为自定义类型的实例填充数据成员的代码如下：

internal static class ModelHelper
{
public static readonly bool IsDebugMode;

static ModelHelper()
{
CompilationSection configSection =
ConfigurationManager.GetSection("system.web/compilation") as CompilationSection;
if( configSection != null )
IsDebugMode = configSection.Debug;
}

/// <summary>
/// 根据HttpRequest填充一个数据实体。
/// 这里不支持嵌套类型的数据实体，且要求各数据成员都是简单的数据类型。
/// </summary>
/// <param name="request"></param>
/// <param name="model"></param>
public static void FillModel(HttpRequest request, object model, string paramName)
{
ModelDescripton descripton = ReflectionHelper.GetModelDescripton(model.GetType());

object val = null;
foreach( DataMember field in descripton.Fields ) {

// 这里的实现方式不支持嵌套类型的数据实体。
// 如果有这方面的需求，可以将这里改成递归的嵌套调用。

val = GetValueByKeyAndTypeFrommRequest(
request, field.Name, field.Type.GetRealType(), paramName);
if( val != null )
field.SetValue(model, val);
}
}

/// <summary>
/// 读取一个HTTP参数值。这里只读取QueryString以及Form
/// </summary>
/// <param name="request"></param>
/// <param name="key"></param>
/// <returns></returns>
public static string GetHttpValue(HttpRequest request, string key)
{
string val = request.QueryString[key];
if( val == null )
val = request.Form[key];

return val;
}

public static object GetValueByKeyAndTypeFrommRequest(
HttpRequest request, string key, Type type, string paramName)
{
// 不支持复杂类型
if( type.IsSimpleType() == false )
return null;

string val = GetHttpValue(request, key);
if( val == null ) {
// 再试一次。有可能是多个自定义类型，Form表单元素采用变量名做为前缀。
if( string.IsNullOrEmpty(paramName) == false ) {
val = GetHttpValue(request, paramName + "." + key);
}

if( val == null )
return null;
}

return SafeChangeType(val.Trim(), type);
}

public static object SafeChangeType(string value, Type conversionType)
{
if( conversionType == typeof(string) )
return value;

if( value == null || value.Length == 0 )
// 空字符串根本不能做任何转换，所以直接返回null
return null;

try {
// 为了简单，直接调用 .net framework中的方法。
// 如果转换失败，则会抛出异常。
return Convert.ChangeType(value, conversionType);
}
catch {
if( IsDebugMode )
throw; // Debug 模式下抛异常
else
return null; // Release模式下忽略异常（防止恶意用户错误输入）
}
}

}

在给自定义的数据类型实例加载数据前，需要先知道这个实例对象有哪些属性以及字段，这个过程的代码如下：

/// <summary>
/// 返回一个实体类型的描述信息（全部属性及字段）。
/// </summary>
/// <param name="type"></param>
/// <returns></returns>
public static ModelDescripton GetModelDescripton(Type type)
{
if( type == null )
throw new ArgumentNullException("type");

string key = type.FullName;
ModelDescripton mm = (ModelDescripton)s_modelTable[key];

if( mm == null ) {
List<DataMember> list = new List<DataMember>();

(from p in type.GetProperties(BindingFlags.Instance | BindingFlags.Public)
select new PropertyMember(p)).ToList().ForEach(x=>list.Add(x));

(from f in type.GetFields(BindingFlags.Instance | BindingFlags.Public)
select new FieldMember(f)).ToList().ForEach(x => list.Add(x));

mm = new ModelDescripton { Fields = list.ToArray() };
s_modelTable[key] = mm;
}
return mm;
}

在拿到一个类型的所有属性以及字段的描述信息后，就可以通过循环的方式，根据这些数据成员的名字去QueryString，Form读取所需的数据了。

参数准备好了，前面的调用就应该没有问题了吧？

MyMVC框架的实现原理 - 处理返回值

MyMVC框架处理返回值的时机是在ExecuteAction方法中（前面有那段代码）。
这里只做个简单的补充说明。

我为Action的结果定义了一个接口：

public interface IActionResult
{
void Ouput(HttpContext context);
}

框架内实现了4种ActionResult：

/// <summary>
/// 表示一个用户控件结果（用户控件将由框架执行）
/// </summary>
public sealed class UcResult : IActionResult

/// <summary>
/// 表示一个重定向的结果
/// </summary>
public sealed class RedirectResult : IActionResult

/// <summary>
/// 一个Json对象结果
/// </summary>
public sealed class JsonResult : IActionResult

/// <summary>
/// 表示一个页面结果（页面将由框架执行）
/// </summary>
public sealed class PageResult : IActionResult

要输出返回值的时候，不仅使用了IActionResult接口，我还使用下面这个调用：

context.Response.Write(result.ToString());

不要小看了ToString()的调用。
对于自定义的数据类型来说，可以用它来控制最终输出给客户端的是JSON或者是XML，或者是您自己定义的文本序列化格式（比如：特殊分隔符拼接而成），因此，它有足够的能力可以取代JsonResult类型，而且同样不影响Action的单元测试。
ToString()的强大原因在于它是个虚方法，可以被派生类重写。

所以，如果您只打算返回一个数据实体对象给客户端，那么既可以实现IActionResult接口，还可以重写ToString方法。

MyMVC框架的实现原理 - 如何返回HTML片段

AJAX调用中，虽然以返回数据居多，但有时也会要求返回一段HTML，毕竟拼HTML代码在服务端会容易些。

MyMVC提供UcResult类型，用来将一个用户控件的呈现结果做为HTML输出。当然了，您也可以创建一个Page，采用Page来输出HTML，那么就要用到PageResult类型了。它们的使用代码如下：

由于我从来不用Page输出一段HTML，因此没有准备在Ajax中使用PageResult的示例。但是，它们的使用方法是一样，因为：PageResult和UcResult的构造函数有着一致的签名方式。

再来说说创建UcResult对象那行代码：传入二个参数，第一个参数表示用户控件的位置（View），第二个参数表示呈现用户控件所需的数据（Model）。至于这个地方为什么要设计二个参数，请关注我的后续博客，因为它涉及到MVC的核心思想，今天的博客不打算谈这个话题。

MyMVC框架的实现原理 - 多命名空间的支持

前面的示例代码都是演示了如何设计一个能供JS调用的Action，事实上，您也看到了，其实就是加了个[Action]的方法而已，没有其它的特别之处了。不过，在现实开发中，类型的名字可能会冲突。比如：.NET就引入了命名空间来处理这种冲突的类名。

MyMVC支持同名的Controller的名字吗？
答案是肯定的：支持。

例如，我有下面二个类型。注意它们的名字是相同的。

namespace Fish.AA
{
public class AjaxTest
{
[Action]
public int Add(int a, int b)
{
return a + b;
}
}
}

namespace Fish.BB
{
public class AddInfo
{
public int A;
public int B;
}

public class AjaxTest
{
[Action]
public int Add(AddInfo info)
{
return info.A + info.B + 10; // 故意写错。
}
}
}

这二个类型不仅同名，而且还包含了同名的方法。（事实上，方法的签名也可以完全一样。）

那么，对于这种情况，JS如何去调用它们呢？

为了回答这个问题，我特意准备了一个示例，HTML代码如下：

<fieldset>
<legend>Fish.AA.AjaxTest.Add</legend>
<input type="text" id="txtA1" style="width: 50px" value="3" /> +
<input type="text" id="txtB1" style="width: 50px" value="2" /> =
<span id="spanResult1"></span>
<input type="button" id="btnAdd1" value="Add" />
</fieldset>

<p></p>

<fieldset>
<legend>Fish.BB.AjaxTest.Add</legend>
<input type="text" id="txtA2" style="width: 50px" value="3" /> +
<input type="text" id="txtB2" style="width: 50px" value="2" /> =
<span id="spanResult2"></span>
<input type="button" id="btnAdd2" value="Add" />
</fieldset>

客户端的JS代码如下：

$(function(){
$("#btnAdd1").click(function(){
$.ajax({
url: "/Fish.AA.AjaxTest/Add.cspx",
data: {a: $("#txtA1").val(), b: $("#txtB1").val()},
success: function(responseText){
$("#spanResult1").text(responseText);
}
});
});

$("#btnAdd2").click(function(){
$.ajax({
// 以下二个URL地址都是有效的。
//url: "/Fish.BB.AjaxTest.Add.cspx",
url: "/Fish/BB/AjaxTest/Add.cspx",
data: {a: $("#txtA2").val(), b: $("#txtB2").val()},
success: function(responseText){
$("#spanResult2").text(responseText);
}
});
});
});

最终的调用结果如下：

注意：下方的调用结果虽然是错误的，但表示调用的方法是正确的。

让我们再来回顾一下UrlParser类中定义的那个正则表达式吧：

internal static readonly string AjaxUrlPattern
= @"/(?<name>(\w[\./\w]*)?(?=Ajax)\w+)[/\.](?<method>\w+)\.[a-zA-Z]+";

它可以解析这些格式的URL：

/*
可以解析以下格式的URL：（前三个表示包含命名空间的）

/Fish.AA.AjaxTest/Add.cspx
/Fish.BB.AjaxTest.Add.cspx
/Fish/BB/AjaxTest/Add.cspx
/AjaxDemo/GetMd5.cspx
/AjaxDemo.GetMd5.cspx
*/

值得说明的是：这个正则表达式并没有限定用什么样的扩展名，而且也不限制URL中的查询字符串参数。

但是，就算它再强大，还需要在web.config中注册时，要保证匹配的URL能被传入，否则代码根本没有机会运行。

重温httpHandlers的注册：

感谢微软的天才设计，让我可以用通配符的方式写正则表达式。

关于反射的使用

反射。

我想有些人听到这个名字，首先想到的会是低性能，并积极地拒绝使用。
在那些人的心目中，反射就是低性能的代名词。
有趣的是，那些人可能在乐滋滋地用着ASP.NET MVC, WCF, EntryFramewok这类框架。

这里我要说明的是，我并没有说那些框架比较差，而是想说：
那些框架其实也在大量地使用反射，只是微软没有直接说出来而已。
我不知道那些不喜欢的反射的人，知道这些框架在大量使用反射时，会有什么样的想法。

其实想知道一个框架有没有在使用反射，有个简单的识别方法：
1. 它有没有序列化和反序列化。
2. 有没有把类名与方法写在字符串中。
3. 它是不是可以神奇地知道你的任何对象拥有哪些成员？
4. 有没有使用[Attribute]。您不会以为这个标记是给编译器看的吧？

WCF简直是把这些全用上了，而且是在大量使用，ASP.NET MVC，EntryFramewok也没少用！

在实现MyMVC的过程，我大量地使用了反射。
没办法，不用反射，我真的写不出来什么东西。

我认为：没有哪个框架可以不使用反射的。

不使用反射，就意味着：在事先就需要知道将调用哪些类型的哪些方法，这样哪来的灵活性？
反射还有另一个好处就是简化代码，许多类似的代码，就像前面【回忆以往AJAX的实现方式】中总结的那样。那些类似的代码差别在于：参数的名字不同，参数的类型不同，参数的个数不同，要调用的方法以及返回值不同。那些惊呼【非ASP.NET MVC框架不可】的人或许也是厌倦了这些重复劳动，然而，ASP.NET MVC解决这个问题的办法还是反射。

所以，不必害怕反射，它的确会影响性能。
但是，你可以保证你的其它代码都是性能很好吗？
我见过的低性能代码实在是太多了。

反射是会影响性能，但好消息是，它对性能的影响是可以优化的，因此，不同的写法，所表现出来的影响也是不一样的。不过，反射的优化也是个复杂的话题，我打算以后有机会再谈。

结束语

今天的博客演示了我的MVC框架对于AJAX的支持，也展示了在ASP.NET上开发一个框架的具体过程，虽然还未全部说完，但核心部分已经实现了，那就是：根据URL动态调用一个方法。先说AJAX的实现是因为，它是【无界面】的，无界面的东西通常会比较简单。

说到【无界面】又让我想到一些人把微软的ASP.NET MVC用于【无界面】的项目，还在信誓旦旦地说：此类型的项目非微软的ASP.NET MVC不可！

如何评价这些人呢？我只想说：你们还是小点声吧，小心遭人鄙视！

说到写框架，我想还是有必要再说说我写框架的原因：（引用我在博客【用Asp.net写自己的服务框架】中的原话）

自己写框架的好处不在于能将它做得多强大，多完美，而是从写框架的过程中，可以学到很多东西。
一个框架写完了，不在乎要给多少人使用，而是自己感觉有没有进步，这才是关键。

不管你信不信，那些喜欢说【非什么什么不可】的人，通常是从来不会写框架的。

MyMVC的介绍还未结束，下篇博客将会继续，下篇博客的重点在于UI部分的支持和实现，这也正是MVC思想存在的必要性，当然也可以反映出MVC框架的核心价值。

说到这里，我打算给下篇博客做个预告：
MyMVC框架的后半部分在设计上主要体现了MVC这三者的关系，在设计时主要遵循了Martin Fowler大叔的总结：从模型中分离表现和从视图中分离控制器。

最终MyMVC对于UI部分支持的结果是：多个URL可以映射到一个Action，一个Action可以将结果指定给多个View来输出。也就是说：请求与View是一种多对多的关系，而中间的Controller只是一个。至于Model的返回，可以由Controller根据运行的上下文条件给出不同的结果，同一个Model可以交给不同的View来显示，也可以返回不同的Model，分别交给不同的View来显示。

写博客真不容易，为了写这篇博客，我先要写MyMVC框架以及准备示例代码，再准备一些Visio图，最后是文字部分，总共花了整整二个星期。这还不包括前面二篇做为铺垫的博客：【细说 ASP.NET控制HTTP缓存】和【细说 HttpHandler 的映射过程】。但是，每当看到自己写的博客在博客园上拥有较高的【推荐数量】时，感觉宽慰了许多。但愿今天的博客能受欢迎。

感谢 Amy（黄敏）同学为本文所做的校对工作，她已帮我找了好多处文字上的错误。

获取MyMVC框架源代码及示例代码请点击此处进入下载页面

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

细说 HttpHandler 的映射过程

2012-01-29T14:14:00Z

在ASP.NET编程模型中，一个来自客户端的请求要经过一个称为管线的处理过程。在整个处理请求中，相对于其它对象来说，HttpHandler的处理算得上是整个过程的核心部分。由于HttpHandler的重要地位，我前面已经有二篇博客对它过一些使用上的介绍。【用Asp.net写自己的服务框架】中谈到了它的一般使用方法。【细说ASP.NET的各种异步操作】又详细地介绍了异步HttpHandler的使用方式。

今天的博客将着重介绍HttpHandler的配置，创建以及重用过程，还将涉及HttpHandlerFactory的内容。

回顾HttpHandler

HttpHandler其实是一类统称：泛指实现了IHttpHandler接口的一些类型，这些类型有一个共同的功能，那就是可以用来处理HTTP请求。IHttpHandler的接口定义如下：

// 定义 ASP.NET 为使用自定义 HTTP 处理程序同步处理 HTTP Web 请求而实现的协定。
public interface IHttpHandler
{
// 获取一个值，该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。
//
// 返回结果:
// 如果 System.Web.IHttpHandler 实例可再次使用，则为 true；否则为 false。
bool IsReusable { get; }

// 通过实现 System.Web.IHttpHandler 接口的自定义 HttpHandler 启用 HTTP Web 请求的处理。
void ProcessRequest(HttpContext context);
}

有关HttpHandler的各类用法，可参考我的博客【用Asp.net写自己的服务框架】，本文将不再重复说明了。它还有一个异步版本：

// 摘要:
// 定义 HTTP 异步处理程序对象必须实现的协定。
public interface IHttpAsyncHandler : IHttpHandler
{
// 摘要:
// 启动对 HTTP 处理程序的异步调用。
//
// 参数:
// context:
// 一个 System.Web.HttpContext 对象，该对象提供对用于向 HTTP 请求提供服务的内部服务器对象（如 Request、Response、Session
// 和 Server）的引用。
//
// extraData:
// 处理该请求所需的所有额外数据。
//
// cb:
// 异步方法调用完成时要调用的 System.AsyncCallback。如果 cb 为 null，则不调用委托。
//
// 返回结果:
// 包含有关进程状态信息的 System.IAsyncResult。
IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData);
//
// 摘要:
// 进程结束时提供异步处理 End 方法。
//
// 参数:
// result:
// 包含有关进程状态信息的 System.IAsyncResult。
void EndProcessRequest(IAsyncResult result);
}

IHttpAsyncHandler接口的二个方法该如何使用，可参考我的博客【细说ASP.NET的各种异步操作】，本文也将不再重复讲解。

如果我们创建了一个自定义的HttpHandler，那么为了能让它处理某些HTTP请求，我们还需将它注册到web.config中，就像下面这样：

虽然我以前的博客中也曾多次涉及到HttpHandler，但感觉还是没有把它完整地说清楚，今天的博客将继续以前的话题，因为我认为HttpHandler实在是太重要了。

HttpHandler的映射过程

在博客【用Asp.net写自己的服务框架】中，我从MSDN中摘选了一些ASP.NET管线事件，在这些事件中，第10个事件【根据所请求资源的文件扩展名（在应用程序的配置文件中映射），选择实现 IHttpHandler 的类，对请求进行处理】就是本文要介绍的重点事件。这个事件也是HttpHandler创建的地方。

由于IIS6,7在管线事件触发机制上的有一定的差别，本文将以ASP.NET 2.0以及IIS6的运行方式来介绍这个过程，IIS7的集成模式下只是触发机制不同，但事件的绝大部分是一样的。管线事件由HttpApplication控制，由MapHandlerExecutionStep负责封装这个事件的执行过程：

internal class MapHandlerExecutionStep : HttpApplication.IExecutionStep
{
private HttpApplication _application;

void HttpApplication.IExecutionStep.Execute()
{
HttpContext context = this._application.Context;
HttpRequest request = context.Request;

//我删除了一些与本文无关的调用代码

context.Handler = this._application.MapHttpHandler(
context, request.RequestType, request.FilePathObject, request.PhysicalPathInternal, false);
}

Execute()最终调用了MapHttpHandler()方法，这个映射过程是由HttpApplication实现的。
MapHttpHandler方法的实现如下：注意代码中我加入的注释。

/// <summary>
/// 根据虚拟路径映射到具体的HttpHandler对象
/// </summary>
/// <param name="context">HttpContext的实例</param>
/// <param name="requestType">GET, POST ...</param>
/// <param name="path">一个虚拟路径映射的字符串: /abc.aspx</param>
/// <param name="pathTranslated">要请求的物理文件的路径</param>
/// <param name="useAppConfig"></param>
/// <returns>具体的HttpHandler对象</returns>
internal IHttpHandler MapHttpHandler(HttpContext context, string requestType,
VirtualPath path, string pathTranslated, bool useAppConfig)
{
// 说明：这段代码是我精简后的代码。为了便于理解，我去掉了一些与请求无关的代码行。

IHttpHandler handler = (context.ServerExecuteDepth == 0) ? context.RemapHandlerInstance : null;

//用于将当前线程的运行帐号切换为web.config指定的帐号
using( new ApplicationImpersonationContext() ) {

// 如果之前调用过context.RemapHandler()，则直接返回那个HttpHandler
// 把这个判断放在这里似乎没有意义，应该放在using前面，那样岂不是更快吗？【fish li个人意见】
if( handler != null )
return handler;

// 到 <httpHandlers> 配置中查找一个能与requestType以及path匹配的配置项
HttpHandlerAction mapping = this.GetHandlerMapping(context, requestType, path, useAppConfig);
if( mapping == null )
throw new HttpException("Http_handler_not_found_for_request_type");

// 获取IHttpHandlerFactory对象，这是比较重要的调用。
IHttpHandlerFactory factory = this.GetFactory(mapping);

// 尝试转换成IHttpHandlerFactory2对象。设计二个IHttpHandlerFactory的原因与参数的可见类型有关。
IHttpHandlerFactory2 factory2 = factory as IHttpHandlerFactory2;

// 调用IHttpHandlerFactory对象的GetHandler方法获取具体的HttpHandler对象
if( factory2 != null )
handler = factory2.GetHandler(context, requestType, path, pathTranslated);
else
handler = factory.GetHandler(context, requestType, path.VirtualPathString, pathTranslated);

// 将这二个对象都添加到【临时】回收列表。在管线处理的结尾处，会调用HandlerWithFactory.Recycle()
// 进而会调用factory.ReleaseHandler()，最后会丢掉_handlerRecycleList的引用。
// 因此factory的重用与这里无关，它只可能会影响handler
this._handlerRecycleList.Add(new HandlerWithFactory(handler, factory));
}
return handler;
}

今天的代码将着重分析这段代码，以揭示HttpHandler的映射过程。

在这段代码中，有3个主要的调用过程：
1. this.GetHandlerMapping(context, requestType, path, useAppConfig)
2. this.GetFactory(mapping)
3. factory.GetHandler(context, requestType, path.VirtualPathString, pathTranslated)
后面将着重分析这三个调用。

HttpContext.RemapHandler()

在MapHttpHandler()方法的开始处，有这么一段代码，不知您注意没有？

IHttpHandler handler = (context.ServerExecuteDepth == 0) ? context.RemapHandlerInstance : null;

if( handler != null )
return handler;

这段代码是什么意思呢？
为了能让您较为简单地理解这段代码的意义，请看我准备的一个示例：
我创建了一个TestRemapHandler.ashx文件：

<%@ WebHandler Language="C#" Class="TestRemapHandler" %>

using System;
using System.Web;

public class TestRemapHandler : IHttpHandler {

public void ProcessRequest (HttpContext context) {
context.Response.ContentType = "text/plain";
context.Response.Write("Hello TestRemapHandler");
}

public bool IsReusable {
get {
return false;
}
}
}

至于这个文件在运行时能输出什么，我想我就不用截图了。
接下来，我再创建一个Global.asax文件，并写了一个事件处理方法：

//protected void Application_PostResolveRequestCache(object sender, EventArgs e)
//{
// HttpApplication app = (HttpApplication)sender;
// if( app.Request.FilePath.EndsWith(".ashx", StringComparison.OrdinalIgnoreCase) )
// app.Context.RemapHandler(new MyTestHandler());
//}

// 或者是下面这样

protected void Application_PostResolveRequestCache(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
if( app.Request.FilePath.EndsWith("/TestRemapHandler.ashx", StringComparison.OrdinalIgnoreCase) )
app.Context.RemapHandler(new MyTestHandler());
}

MyTestHandler是我定义的一个自定义的HttpHandler，后面的示例也会用到它，所以，我现在就将它的实现代码贴出来：

public class MyTestHandler : IHttpHandler
{
private Counter _counter = new Counter();

public bool IsReusable
{
get { return true; }
}

public void ProcessRequest(HttpContext context)
{
_counter.ShowCountAndRequestInfo(context);
}
}

类型Counter是一个简单的计数器，它的实现如下：

/// <summary>
/// 一个简单的计数器
/// </summary>
public class Counter
{
private int _count;

public void ShowCountAndRequestInfo(HttpContext context)
{
_count++;
context.Response.ContentType = "text/plain";
context.Response.Write("count: " + _count.ToString());
context.Response.Write("\r\n");
context.Response.Write(context.Request.RawUrl);
}
}

现在，您可以想像一下当我再次访问TestRemapHandler.ashx时，会在浏览器中看到什么？

以下是我看到的结果：

从截图中，我们可以看出，服务端的输出并不是TestRemapHandler.ashx产生的，而是由MyTestHandler产生的。这也说明我调用Context.RemapHandler()确实影响了后面的MapHttpHandler过程。现在我们再回过头来再看一下前面那段代码：

IHttpHandler handler = (context.ServerExecuteDepth == 0) ? context.RemapHandlerInstance : null;

if( handler != null )
return handler;

这段代码也主要是为配合HttpContext.RemapHandler()一起工作的。这里要补充的是：context.ServerExecuteDepth的判断是说有没有调用HttpServerUtility.Execute()

小结：如果我们在MapHttpHandler事件前调用HttpContext.RemapHandler()，将会直接影响后面的映射过程，或者说，我们可以直接指定一个HttpHandler，而不是让ASP.NET来替我们来决定。

HttpContext.RemapHandler()的另类用途

我在【用Asp.net写自己的服务框架】曾演示过ASP.NET URL路由的设计思路，虽然那个示例能较好地反映微软的Routing组件的工作方式，但对于示例来说，有些代码还是可以简化的。今天我将使用HttpContext.RemapHandler()来简化那段代码，简化后的版本如下：

internal class MyServiceUrlRoutingModule2 : IHttpModule
{
public void Init(HttpApplication app)
{
app.PostResolveRequestCache += new EventHandler(app_PostResolveRequestCache);
}

private void app_PostResolveRequestCache(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;

// 根据HttpContext，获取合适的HttpHandler，这个过程俗称路由
// 通常就是根据URL去主动寻找一个合适的HttpHandler

// 查找过程仍使用上一版的方法
MyServiceHandler handler = MyServiceUrlRoutingModule.GetHandler(app.Context);
if( handler != null )
// 直接设置已找到的HttpHandler
app.Context.RemapHandler(handler);
}

public void Dispose()
{
}
}

在MyServiceUrlRoutingModule2这个新版本中，基本上跳过了MapHttpHandler()中所有复杂的处理逻辑，因此会更快。

这种方法虽然更简单，但它只能设置一个参数IHttpHandler，因此，如果有其它的参数需要一起传递，则要修改相关的HttpHandler类型，以便容纳需要传递的参数。例如，在【我的服务框架】中，MyServiceHandler类型就专门定义了一个属性ServiceInfo来保存要调用的方法信息。MyServiceUrlRoutingModule.GetHandler()的实现代码如下：

internal static MyServiceHandler GetHandler(HttpContext context)
{
NamesPair pair = FrameworkRules.ParseNamesPair(context.Request);
if( pair == null )
return null;

InvokeInfo vkInfo = ReflectionHelper.GetInvokeInfo(pair);
if( vkInfo == null )
ExceptionHelper.Throw404Exception(context);

MyServiceHandler handler = MyServiceHandlerFactory.GetHandler(vkInfo);
handler.ServiceInfo = new ServiceInfo(pair, vkInfo);
return handler;
}

写到这里，有个问题把我难住了：为什么ASP.NET 3.5 UrlRoutingModule不用RemapHandler()而是采用较复杂的方法呢？难道是为了能保留二个参数吗？但那个【context.Request.Path】没有必要保存呢。实在是没有想通，最后想到ASP.NET 4.0 UrlRoutingModule会不会不一样了？于是，只好再次安装 .net framework 4.0 了（没办法，老家的旧机器上还真没有.net 4.0），结果当我用Reflector.exe找到4.0版本的UrlRoutingModule时，发现它已被移到System.Web.dll中，而且，ASPL.NET 4.0也在使用RemapHandler() ！看来微软当初忘记了这个方法。

GetHandlerMapping()

在MapHttpHandler()方法中，有下面这个调用：

// 到 <httpHandlers> 配置中查找一个能与requestType以及path匹配的配置项
HttpHandlerAction mapping = this.GetHandlerMapping(context, requestType, path, useAppConfig);

接下来，我们再来看一下这个调用的实现代码：

private HttpHandlerAction GetHandlerMapping(HttpContext context, string requestType, VirtualPath path, bool useAppConfig)
{
CachedPathData pathData = null;
HandlerMappingMemo cachedHandler = null;
HttpHandlerAction mapping = null;
if (!useAppConfig)
{
// 先从缓存中查找
pathData = context.GetPathData(path);
cachedHandler = pathData.CachedHandler;
if ((cachedHandler != null) && !cachedHandler.IsMatch(requestType, path))
{
cachedHandler = null;
}
}
if (cachedHandler == null)
{
// 根据配置文件，查找映射
mapping = (useAppConfig ? RuntimeConfig.GetAppConfig().HttpHandlers
: RuntimeConfig.GetConfig(context).HttpHandlers)
.FindMapping(requestType, path);

if (!useAppConfig)
{
// 将查找到的结果放入缓存
cachedHandler = new HandlerMappingMemo(mapping, requestType, path);
pathData.CachedHandler = cachedHandler;
}
return mapping;
}
return cachedHandler.Mapping;
}

代码中的重要阶段，我加了一点注释。我们尤其要注意的FindMapping(requestType, path)的那个调用。
但前面的那个RuntimeConfig.GetAppConfig().HttpHandlers 和RuntimeConfig.GetConfig(context).HttpHandlers)又可以得到什么结果呢？
为了能让您更容易地理解这个调用，我准备了一段代码，可以直观地显示这个调用结果：

public partial class TestRuntimeConfig : System.Web.UI.Page
{
protected string HttpHandlers;

protected void Page_Load(object sender, EventArgs e)
{
string typeName = typeof(HttpRequest).AssemblyQualifiedName
.Replace("HttpRequest", "Configuration.RuntimeConfig");
Type type = Type.GetType(typeName);

bool useAppConfig = Request.QueryString["useAppConfig"] == "1";

// 由于RuntimeConfig类型的可见性是internal，
// 所以，我不能直接用它声明变量，只能使用object类型
object config = null;

if( useAppConfig )
config = type.InvokeMember("GetAppConfig",
BindingFlags.InvokeMethod | BindingFlags.Static | BindingFlags.NonPublic,
null, null, null);
else
config = type.InvokeMember("GetConfig",
BindingFlags.InvokeMethod | BindingFlags.Static | BindingFlags.NonPublic,
null, null, new object[] { this.Context });

HttpHandlersSection section = (HttpHandlersSection)type.InvokeMember("HttpHandlers",
BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.NonPublic,
null, config, null);

HttpHandlers = string.Format("总共 {0} 个配置项。<br />", section.Handlers.Count) +
string.Join("<br />", (
from h in section.Handlers.Cast<HttpHandlerAction>()
let action = string.Format("path=\"{0}\" verb=\"{1}\" validate=\"{2}\" type=\"{3}\"",
h.Path, h.Verb, h.Validate, h.Type)
select action).ToArray());
}
}

我的示例网站中的web.config中的<httpHandlers>配置节定义如下：

那么，前面的示例代码的运行结果如下：

通过前面分析可知，代码中的HttpHandlers实际就是在运行时所能访问到的<httpHandlers>配置集合。而且，我们在网站中所指定的配置会放在集合的前面，ASP.NET的默认配置会在靠后的位置。接下来的FindMapping(requestType, path)的实现如下：

internal HttpHandlerAction FindMapping(string verb, VirtualPath path)
{
this.ValidateHandlers();
for (int i = 0; i < this.Handlers.Count; i++)
{
HttpHandlerAction action = this.Handlers[i];
if (action.IsMatch(verb, path))
{
return action;
}
}
return null;
}

从代码可以看出，其实所谓的【查找】过程，也就是【逐一匹配】每个在<httpHandlers>定义的配置项。

至于action.IsMatch()的匹配方式，我们可以从调用所传递的参数看出，其实只是判断【verb, path】这二个参数而已。这个匹配过程的实现代码较长，我就不贴出它们的实现代码了，而是打算通过示例来说明它是如何匹配的。

action.IsMatch()的匹配方式也可以算是GetHandlerMapping()的核心过程。而这里的action的类型其实是HttpHandlerAction，它与<httpHandlers>配置项一一对应。我们可以先来看一下MSDN是如何解释这个配置项的：

从MSDN的解释中可以看出：verb,path都可以支持【通配符(*)】，并且可以使用逗号(,)来分隔多个预期项。ASP.NET在实现通配符时，内部使用正则表达式的方式，具体过程可以自己去阅读相关代码。

下面，我将通过一个具体的配置项来分析这些配置参数：

1. path="Ajax*.*.aspx,Ajax*/*.aspx"：表示可以接受【Ajax*.*.aspx】或者【Ajax*/*.aspx】这样的URL格式。
2. verb="*": 表示可以接受所有的HTTP调用，如：GET,POST 等等。
3. type="MySimpleServiceFramework.AjaxServiceHandler, MySimpleServiceFramework": 表示当某个请求匹配path,verb时，交给MySimpleServiceFramework程序集中的MySimpleServiceFramework.AjaxServiceHandler来处理请求。
4. validate="true"：表示在第一次读取<httpHandlers>时，验证type的设置是否有效。如果此项设为false，则表示延迟验证（创建时）。默认值：true

对于这4个属性，有2个比较重要：
1. type: type中的字符串必须能在运行时找到一个可创建的类型，且该类型必须实现IHttpHandler或者IHttpHandlerFactory接口。
2. path: 在很多资料以及技术书籍中，一般都设置为某类文件扩展名，如：*.xxx ，事实上，我们完全可以设置为一个URL模式，而且还可以设置多个URL模式。比如上面的配置示例中的path参数，具体在使用时，可以响应来自客户端的以下请求：

$(function(){
$("#btnSubmit").click( function(){
$.ajax({
// 注意：下面的二个url地址都是可以使用的。
url: "/AjaxServices/GetMd5.aspx",
//url: "/AjaxServices.GetMd5.aspx",

// 注意：下面的二种type的设置也都是可以使用的。
type: "POST",
//type: "GET",

data: { str: $("#txtInput").val() },
dataType: "text",
success: function(responseText){
$("#md5Result").text(responseText);
}
});
});
});

注意：在path中直接使用某个扩展名的好处是不受配置项的顺序影响，而且容易理解，因为可读性较好。

这里要补充一点：MySimpleServiceFramework是我在博客【用Asp.net写自己的服务框架】中实现的那个框架。
在服务端，可以使用下面的代码来处理前面客户端发出的请求：

[MyService]
public class AjaxServices
{
[MyServiceMethod]
public string GetMd5(string str)
{
if( str == null )
str = string.Empty;

byte[] bb = (new MD5CryptoServiceProvider()).ComputeHash(Encoding.Default.GetBytes(str));
return BitConverter.ToString(bb).Replace("-", "");
}
}

前面的示例配置中：path="Ajax*.*.aspx,Ajax*/*.aspx" ，我使用了aspx这个扩展名。
我想大家都知道aspx这个扩展名是ASP.NET可处理的扩展名，为什么我还可以使用呢？
其实这个问题的答案在我前面的截图以及FindMapping的实现代码中：由于我们指定的配置要优先于ASP.NET的默认配置，所以先有机会参与匹配，并能匹配成功。

小结：在GetHandlerMapping()过程中，会根据请求的URL地址以及HTTP调用动作（GET,POST），返回一个在<httpHandlers>定义的配置项（HttpHandlerAction类型）。

GetFactory()

在GetHandlerMapping()返回一个HttpHandlerAction的配置项后，HttpApplication会调用this.GetFactory(mapping);获取一个IHttpHandlerFactory ，本小节将来分析这个过程。

首先，我们还是来看一下GetFactory的实现代码：

private Hashtable _handlerFactories = new Hashtable();

private IHttpHandlerFactory GetFactory(HttpHandlerAction mapping)
{
// 先尝试从内部缓存中获取
HandlerFactoryCache cache = (HandlerFactoryCache) this._handlerFactories[mapping.Type];
if (cache == null)
{
// 创建一个缓存项并保存
cache = new HandlerFactoryCache(mapping);
this._handlerFactories[mapping.Type] = cache;
}
// 返回工厂对象
return cache.Factory;
}

代码中做了哪些事情，我在注释中有说明。这个方法的最后一定会返回一个IHttpHandlerFactory的实例。

看到这里，您觉得奇怪吗？
可能我们仅仅只是实现了一个自定义的IHttpHanlder接口，并没有实现IHttpHandlerFactory，那么ASP.NET是如何处理的呢？

请注意 new HandlerFactoryCache(mapping) 这行代码，这可不是简单地创建一个缓存对象，具体实现代码如下：

internal class HandlerFactoryCache
{
private IHttpHandlerFactory _factory;

internal HandlerFactoryCache(HttpHandlerAction mapping)
{
// 根据HttpHandlerAction配置中的type字符串创建对应类型的对象
object obj2 = mapping.Create();

if( obj2 is IHttpHandler ) {
// 如果我们的配置是一个IHttpHandler，
// 那么ASP.NET会为我们包装成一个HandlerFactoryWrapper
this._factory = new HandlerFactoryWrapper((IHttpHandler)obj2, this.GetHandlerType(mapping));
}
else {
// 如果不是IHttpHandler以及IHttpHandlerFactory，就抛出异常
if( !(obj2 is IHttpHandlerFactory) ) {
throw new HttpException("Type_not_factory_or_handler");
}
this._factory = (IHttpHandlerFactory)obj2;
}
}

代码中，我加入的注释已经回答了前面提出的问题：如果是一个IHttpHandler对象，ASP.NET会再创建一个HandlerFactoryWrapper对象来包装IHttpHandler对象，如果是IHttpHandlerFactory对象，则直接返回。
我们再来看一下HandlerFactoryWrapper的实现代码：

internal class HandlerFactoryWrapper : IHttpHandlerFactory
{
private IHttpHandler _handler;
private Type _handlerType;

internal HandlerFactoryWrapper(IHttpHandler handler, Type handlerType)
{
this._handler = handler;
this._handlerType = handlerType;
}

public IHttpHandler GetHandler(HttpContext context,
string requestType, string url, string pathTranslated)
{
if( this._handler == null )
this._handler = (IHttpHandler)HttpRuntime.CreateNonPublicInstance(this._handlerType);

return this._handler;
}

public void ReleaseHandler(IHttpHandler handler)
{
// 一个HttpHandler是否能重用，这里就是一个典型的实现方式
if( !this._handler.IsReusable )
this._handler = null;
}
}

小结：HttpApplication会根据web.config中的配置去查找一个匹配的IHttpHandlerFactory类型, 即使我们配置的是自定义的IHttpHandler类型，而不是IHttpHandlerFactory类型，调用过程依然如此。

GetHandler()

在ASP.NET中，定义了二个版本的HttpHandlerFactory接口，分别为：

public interface IHttpHandlerFactory
{
IHttpHandler GetHandler(HttpContext context,
string requestType, string url, string pathTranslated);
void ReleaseHandler(IHttpHandler handler);
}

internal interface IHttpHandlerFactory2 : IHttpHandlerFactory
{
IHttpHandler GetHandler(HttpContext context,
string requestType, VirtualPath virtualPath, string physicalPath);
}

设计IHttpHandlerFactory接口的目的是为了在创建和重用IHttpHandler对象时，保留了足够的扩展机会，而IHttpHandlerFactory2则是一个仅供微软使用的内部接口（因为VirtualPath类型的可见性也是internal）。

我们都知道aspx, ashx能直接处理HTTP请求，它们都实现了IHttpHandler接口。它们能处理HTTP请求也因为ASP.NET已经配置过它们。以下是它们的默认配置：

有趣的是：PageHandlerFactory和SimpleHandlerFactory都实现了IHttpHandlerFactory2接口，因此，它们都可以根据要请求的路径创建一个IHttpHandler实例。

从ASP.NET的默认配置，我们也可以看到：type参数是可以设置为一个实现IHttpHandlerFactory接口的类型，而不一定要求是实现IHttpHandler接口的类型。

小结：HttpApplication在处理请求时，并不会直接创建一个IHttpHandler的实例，而是先获取一个IHttpHandlerFactory的对象，再以接口的形式调用GetHandler()方法来获取一个IHttpHandler实例。

IHttpHandler.IsReusable

IHttpHandler接口有个IsReusable属性。MSDN对这个属性的说明也非常简单：

获取一个值，该值指示其他请求是否可以使用 IHttpHandler 实例。

按照这个说明，当我们直接在创建一个实现IHttpHandler的类型，并在web.config中注册到一个自定义的扩展名时，情况会如何呢？
我们再来看一下前面所提过的示例代码（MyTestHandler的）：

web.config中的配置为：

当我连续5次访问 http://localhost:51652/abc.test?id=1 时，会在浏览器中看到以下输出结果：

从这个截图来看，显然：MyTestHandler的实例被重用了。

我想很多人都创建过ashx文件，IDE会为我们创建一个实现了IHttpHandler接口的类型，在实现IsReusable属性时，一般都会这样：

public bool IsReusable {
get {
return false;
}
}

有些人看到这个，会想：如果返回true，就可以重用IHttpHandler实例，达到优化性能的目的。但事实上，即使你在ashx中返回true也是无意义的，因为您可以试着这样去实现这个属性：

public bool IsReusable
{
get { throw new Exception("这里不起作用。"); }
}

如果您访问那个ashx，会发现：根本没有异常出现！
因此，我们可以得出一个结论：默认情况下，IsReusable不能决定一个ashx的实例是否能重用。

这个结果太奇怪了。为什么会这样呢？

前面我们看到*.ashx的请求交给SimpleHandlerFactory来创建相应的HttpHandler对象，然而当ASP.NET调用SimpleHandlerFactory.GetHandler()方法时，该方法会直接创建并返回我们实现的类型实例。换句话说：SimpleHandlerFactory根本不使用IHttpHandler.IsReusable的属性，因此，这种情况下，想重用ashx的实例是不可能的事，所以，即使我在实现IsReusable属性时，写上抛异常的语句，根本也不会被调用。

同样的事情还发在aspx页面的实例上，所以，在默认情况下，我们不可能重用aspx, ashx的实例。

至于aspx的实例不能重用，除了和PageHandlerFactory有关外，还与Page在实现IHttpHandler.IsReusable有关，以下是Page的实现方式：

public bool IsReusable
{
get { return false; }
}

从代码可以看到微软在Page是否重用上的明确想法：就是不允许重用！

由于Page的IsReusable属性我们平时看不到，我想没人对它的重用性有产生过疑惑，但ashx就不同了，它的IsReusable属性的代码是摆在我们面前的，任何人都可以看到它，试想一下：当有人发现把它设为true or false时都不起作用，会是个什么想法？估计很多人会郁闷。

小结：IHttpHandler.IsReusable并不能决定是否重用HttpHanlder ！

实现自己的HttpHandlerFactory

通过前面的示例，我们也看到了，虽然IHttpHandler定义了一个IsReusable属性，但它并不能决定此类型的实例是否能得到重用。重不重用，其实是由HttpHandlerFactory来决定的。ashx的实例不能重用就是一个典型的例子。

下面我就来演示如何实现自己的HttpHandlerFactory来重用ashx的实例。示例代码如下（注意代码中的注释）：

internal class ReusableAshxHandlerFactory : IHttpHandlerFactory
{
private Dictionary<string, IHttpHandler> _cache
= new Dictionary<string, IHttpHandler>(200, StringComparer.OrdinalIgnoreCase);

public IHttpHandler GetHandler(HttpContext context,
string requestType, string virtualPath, string physicalPath)
{
string cacheKey = requestType + virtualPath;

// 检查是否有缓存的实例（或者可理解为：被重用的实例）
IHttpHandler handler = null;
if( _cache.TryGetValue(cacheKey, out handler) == false ) {
// 根据请求路径创建对应的实例
Type handlerType = BuildManager.GetCompiledType(virtualPath);

// 确保一定是IHttpHandler类型
if( typeof(IHttpHandler).IsAssignableFrom(handlerType) == false )
throw new HttpException("要访问的资源没有实现IHttpHandler接口。");

// 创建实例，并保存到成员字段中
handler = (IHttpHandler)Activator.CreateInstance(handlerType, true);

// 如果handler要求重用，则保存它的引用。
if( handler.IsReusable )
_cache[cacheKey] = handler;
}

return handler;
}

public void ReleaseHandler(IHttpHandler handler)
{
// 不需要处理这个方法。
}
}

为了能让HttpHandlerFactory能在ASP.NET中运行，还需要在web.config中注册：

有了这个配置后，我们可以创建一个Handler2.ashx来测试效果：

<%@ WebHandler Language="C#" Class="Handler2" %>

using System;
using System.Web;

public class Handler2 : IHttpHandler {

private Counter _counter = new Counter();

public bool IsReusable
{
get { return true; }
}

public void ProcessRequest(HttpContext context)
{
_counter.ShowCountAndRequestInfo(context);
}
}

在多次访问Handler2.ashx后，我们可以看到以下效果：

再来看看按照IDE默认生成的IsReusable会在运行时出现什么结果。示例代码：

<%@ WebHandler Language="C#" Class="Handler1" %>

using System;
using System.Web;

public class Handler1 : IHttpHandler {

private Counter _counter = new Counter();

public bool IsReusable
{
get {
// 如果在配置文件中启用ReusableAshxHandlerFactory，那么这里将会被执行。
// 可以尝试切换下面二行代码测试效果。

//throw new Exception("这里不起作用。");
return false;
}
}

public void ProcessRequest(HttpContext context)
{
_counter.ShowCountAndRequestInfo(context);
}
}

此时，无论我访问Handler1.ashx多少次，浏览器始终显示如下结果：

如果我启用代码行 throw new Exception("这里不起作用。"); 将会看到以下结果：

终于，我们期待的黄页出现了。
此时，如果我在web.config中将ReusableAshxHandlerFactory的注册配置注释起来，发现Handler1.ashx还是可以访问的。

回想一下前面我们看到的IHttpHandlerFactory接口，它还定义了一个ReleaseHandler方法，这个方法又是做什么的呢？对于这个方法，MSDN也有一句简单的说明：

使工厂可以重用现有的处理程序实例。

对于这个说明，我认为并不恰当。如果按照HandlerFactoryWrapper的实现方式，那么这个解释是正确的。但我前面的示例中，我在实现这个方法时，没有任何代码，但一样可以达到重用HttpHandler的目的。因此，我认为重用的方式取决于具体的实现方式。

小结：IHttpHandler.IsReusable并不能完全决定HttpHandler的实例是否能重用，它只起到一个指示作用。HttpHandler如何重用，关键还是要由HttpHandlerFactory来实现。

是否需要IsReusable = true ？

经过前面文字讲解以及示例演示，有些人可能会想：我在实现IHttpHandler的IsReusable属性时，要不要返回true呢？（千万别模仿我的示例代码抛异常哦。）

如果返回true，则HttpHandler能得到重用，或许某些场合下，是可以达到性能优化的目的。
但是，它也可能会引发新的问题：HttpHandler实例的一些状态会影响后续的请求。
也正是由于这个原因，aspx, ashx 的实例在默认情况下，都是不重用的。

有些人还可能会担心：被重用的HttpHandler是否有线程安全问题？
理论上，在ASP.NET中，只要使用static的数据成员都会有这个问题。不过，这里所说的被重用的单个HttpHandler实例在处理请求过程中，只会被一个线程所调用，因此，它的实例成员还是线程安全的。但有一点需要注意：在HttpHandlerFactory中实现重用HttpHandler时，缓存HttpHandler的容器要保证是线程安全的。

如果您希望重用HttpHandler来提升程序性能，那么我建议应该考虑以下问题：
HttpHandler的所有数据成员都能在处理请求前初始化。（通常会在后期维护时遗忘，尤其是多人维护时）

小结：在通常情况下，当实现IsReusable时返回false，虽然性能上不是最优，但却是最安全的做法。

HttpHandlerFactory的主要用途

前面示例演示了如何使用HttpHandlerFactory来重用HttpHandler，但设计HttpHandlerFactory并不是完全为了这个目的，它的主要用途还是如何创建HttpHandler，而且定义IHttpHandlerFactory的主要目的是为了扩展性。

我想很多人也许使用过 Web Service ，它运行在ASP.NET平台上，自然也有对应的HttpHandler，我们来看看asmx这个扩展名是如何映射的。

接着找WebServiceHandlerFactory，最后发现是这样创建的HttpHandler :

internal IHttpHandler CoreGetHandler(Type type,
HttpContext context, HttpRequest request, HttpResponse response)
{
// ..... 已删除一些无关的代码

bool isAsync = protocol.MethodInfo.IsAsync;
bool enableSession = protocol.MethodAttribute.EnableSession;
if( isAsync ) {
if( enableSession ) {
return new AsyncSessionHandler(protocol);
}
return new AsyncSessionlessHandler(protocol);
}
if( enableSession ) {
return new SyncSessionHandler(protocol);
}
return new SyncSessionlessHandler(protocol);
}

这才是Factory嘛！

老实说，看到这几句话，我是眼前一亮：用HttpHandlerFactory来动态处理【是否支持Session】实在是太合适了。

这里有必要补充一下：

internal class SyncSessionHandler : SyncSessionlessHandler, IRequiresSessionState
{
}

小结：HttpHandlerFactory用途并非是为了专门处理HttpHandler的重用，它只是一个Factory，WebServiceHandlerFactory从另一个角度向我们展示了HttpHandlerFactory在扩展性方面所体现的重要作用。

点击此处下载示例代码

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接

细说 ASP.NET控制HTTP缓存

2012-01-11T15:55:00Z

在上篇博客【细说 ASP.NET Cache 及其高级用法】中，我给大家介绍了ASP.NET Cache，这种服务端使用的缓存API 。在我们开发一个ASP.NET网站的过程中，其实有很多地方都是可以使用缓存的，只是由于ASP.NET是一种基于服务端的开发平台，自然我们也经常在服务端的代码中使用各类缓存技术，然而，由于WEB应用程序的服务对象是客户端的浏览器，通常来说，我们并不能直接控制浏览器的行为，但是，浏览器却可以根据后台网站的指示，采取一些优化的方式来更快地呈现页面。客户端浏览器也有自己的缓存机制，通常浏览器也使用缓存来优化一些页面的显示过程，不过，我们并不能直接使用C#代码控制浏览器的缓存操作，但我们可以告诉浏览器如何使用缓存，从而达到优化网站性能的目的。

这次博客的主题是：用ASP.NET控制HTTP请求过程中浏览器缓存的一些方法。

正常的HTTP请求过程

在开始介绍浏览器在HTTP请求过程前，我想有必要先来看一下浏览器请求一个普通ASPX页面的过程。
说明：本文在介绍HTTP请求过程时，会大量使用Fiddler来分析具体的请求过程。

上图是一个普通的ASPX页面的请求过程，说它普通是因为：我在创建这个页面后，没对它做任何缓存方面的处理。
图片中我们可以可以看到服务器的响应状态为：HTTP/1.1 200 OK，这是一个服务器成功响应的标志。
另外，要注意图片中的Cache响应头部分，我之所以就红线框出来，是想提醒您注意这块的内容将在后面的小节中发生改变，到时候请注意对比它们。而这里所反映的情况其实也只是默认值而已，它并不表示此页面需要缓存。

缓存页的请求过程

下面再来看一个缓存页面的请求过程：

对比上一张图片中可以看出，现在多了【max-age】，【Expires】以及【Last-Modified】这三个响应头。

这三个头的含义如下：
1. max-age，Expires：要表达的意思基本差不多。max-age表示某次HTTP的响应结果应该缓存多少秒。
而Expires是说某次HTTP的响应结果应缓存到什么时候过期，此时间是一个UTC时间。
另一个Date头表示HTPP响应的发出时间，我们可以发现 Date + max-age = Expires
2. Last-Modified：服务端告诉客户端本次响应返回的HTTP文档的最后修改时间。这个头与304的实现有关，后面再来解释。

分析了HTTP请求过程后，我们再来看一下服务端的页面是什么样子的：

<%@ Page Language="C#" %>
<%@ OutputCache Duration="10" VaryByParam="None" %>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>http://www.cnblogs.com/fish-li/</title>
</head>
<body>
<p>页面生成时间：<%= DateTime.Now.ToString() %></p>
<p><a href="Default.aspx">回到首页</a>
<a href="<%= Request.RawUrl %>">刷新本页</a>
</p>
</body>
</html>

注意：上面代码中最关键的一行代码为：

<%@ OutputCache Duration="10" VaryByParam="None" %>

正是由于使用了这个OutputCache指令，最后才会输出上面那几个响应头，用来告诉浏览器此页面需要缓存10秒钟。

说到这里，可能有些人想有疑惑了：缓存页在什么时候会起到什么作用呢？
为了演示缓存页所带来的现实意义，我将点击页面的这些链接并以截图的形式来说明：在一系列请求过程中页面的显示情况，并以页面的显示结果来分析缓存所起的作用。

先来看看这个页面的显示截图：

页面很简单，主要是显示了页面的生成时间与一个刷新链接。从上面提供的页面代码，我们应该能知道这个页面如果是由服务端生成的，则会显示当前的时间。

不过呢，当我一直（频繁）点击【刷新本页】那个链接时，页面的时间并没有发生改变，当我发现时间改变时，页面已显示成这个样子了：

由于测试过程中，我一直打开了Fiddler，正好我也把Fiddler监视到的请求结果截图下来了：

从Fiddler中，我看到FireFox其实只发生了二次请求，但我点击那个【刷新本页】起码超过10次。

以上的这一切，只说明一个事实：如果页面需要跳转到某个缓存页时，且那个缓存页还没过期，那么浏览器并不会发起到服务器的请求，而是使用缓存页。

小结：页面缓存所带来的好处是：缓存页面在过期前，用户通过点击跳转链接所引发的后续访问，并不会再次请求服务器。这对服务器来说可以减少许多访问次数，因此使用这个特性可以很好地改善程序性能。

缓存页的服务端编程

前面演示了使用OutputCache指令所产生的缓存页的效果，由于那些指令需要在页面的设计阶段就写到页面上，因此显得不够灵活，不能在运行时调整，虽然ASP.NET也允许我们使用CacheProfile来引入定义在Web.config中的配置，但配置还是没有运行时的代码灵活。我们再来看看如何用代码来实现上面的效果。

其实用代码实现缓存页也很简单，只需要这样就可以了：

protected void Page_Load(object sender, EventArgs e)
{
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetExpires(DateTime.Now.AddSeconds(10.0));
}

其实关键也就是对Response.Cache的调用。
注意：Response.Cache与我上篇【细说 ASP.NET Cache 及其高级用法】博客所讲的Cache不是一回事，二者完全不相干。
Response.Cache提供：用于设置缓存特定的 HTTP 标头的方法和用于控制 ASP.NET 页输出缓存的方法。

我们还是来说前面的二段示例代码。可能有些人会想，它们最终的结果真的会是一致的吗？

要想回答这个问题，我想有必要看一下前面用OutputCache指令的那个页面最终运行的代码是个什么样子的。

在ASP.NET的临时编译目录中，我找到了前面那个文件的一个由ASP.NET处理后的版本：

private static System.Web.UI.OutputCacheParameters @__outputCacheSettings = null;

public demo1_aspx() {
// ........ 删除掉一些与Cache无关的代码
if ((global::ASP.demo1_aspx.@__outputCacheSettings == null)) {
System.Web.UI.OutputCacheParameters outputCacheSettings;
outputCacheSettings = new System.Web.UI.OutputCacheParameters();
outputCacheSettings.Duration = 20;
outputCacheSettings.VaryByParam = null;
global::ASP.demo1_aspx.@__outputCacheSettings = outputCacheSettings;
}
}
protected override void FrameworkInitialize() {
base.FrameworkInitialize();
// ........
this.InitOutputCache(global::ASP.demo1_aspx.@__outputCacheSettings);
this.Request.ValidateInput();
}

我们可以看到页面针对OutputCache指令的设置，最终会调用Page类定义一个方法中：

protected internal virtual void InitOutputCache(OutputCacheParameters cacheSettings)

那个方法实在太长，最终的处理方式也还是在调用this.Response.Cache，有兴趣的可以自己去看看那个方法。至于这个方法的参数为什么是OutputCacheParameters，我想这个容易理解：方便将OutputCache指令的参数全部一起传入嘛。

所以，也正因为这个缘故，我们也可以直接在代码中调用Response.Cache的一些方法来实现相同的效果，由于代码可以在运行时根据各种参数调整缓存策略，因此会更加灵活，而且可以采用基类的继承方式来简化实现。

注意：如果使用OutputCache指令再配合OutputCache Module的使用，可以实现304的效果。

什么是304应答？

通过前面的示例，我们已经看到缓存带来的好处：那就是可以减少到服务器的访问，由于不访问服务器就能显示页面，这对于服务器来说，能减轻一定的访问压力。但是，如果用户强制刷新浏览器，那么浏览器将会忽略缓存页，直接向服务器重新发起请求。

也就是说：缓存页在用户强制刷新浏览器时会无效。
但是，我们之所以使用缓存页，是因为我们希望告诉浏览器：这些数据在一定时间内，并不会发生变化，因此根本不需要再次请求服务器了。然而，我们不能阻止用户的行为。由于浏览器的重新访问，我们原来设想的缓存想法将会落空，最后的结果是：页面在服务器中重新执行，产生的HTML代码将重新发送到客户端。而这一重新刷新的结果可能也是无意义的，因为数据可能根本没有发生变化，因此得到的页面也是不可能有变化的。

再来举个简单的例子来说吧：客户端要浏览一张图片。当浏览器第一次要访问图片时，浏览器肯定是没有它的任何缓存记录的，此时它去访问服务器，服务器也返回图片的内容了。但由于图片可能会被多个页面所引用，而它被修改的可能性是很小的。因此没有必要为同一浏览器的多次请求都去读取图片并返回图片的内容，这样做既影响性能也学浪费带宽。于是，像IIS这样服务器软件针对这类静态文件的访问时，都会在响应头上输出一些标记，用来告之浏览器这个文件你可以缓存起来了。

还是回到前面所说的【用户强制刷新】问题，此时的IIS又会如何处理呢？请看下图：

注意哦，此时除了HTTP状态码变成304之外，没有任何数据返回哦。

为了让您对304应答有个深刻的印象，我截了一张状态码为200的图片响应结果：

通过这二张图片的对比，现在看清楚了吧：304和200并不只是数字上的差别，最重要的差别在于有没有返回结果。

没有返回结果，浏览器该如何显示？
您会有这样的疑虑吗？
其实不用担心，此时浏览器会使用它缓存版本来显示。也就是说：不管用户如何强制刷，服务器就是不返回结果，但仍然可以正常显示。

显然，这个效果就是我们想要的。
前面所说的缓存页遭用户强刷的问题，如果采用这种方法，就比较完美了。
不过，有一点我要提醒您：Visual Studio自带的那个WebDev.WebServer.exe不支持304应答，所以您就不要拿它试验了，不会有结果的。

如何编程实现304应答

前面我们看到了304应答的效果。不过，在ASP.NET中，我们开发的程序，是动态页面，而不是图片，我们更希望某个页面能以这种方式缓存一段时间，我想这个需求或许会更有意义。

下面，我就来演示如何通过编程的方式实现它。
接下来的示例中，页面的显示还是那个样，显示页面在服务器上产生的时间，时间变化了，说明页面被重新执行了。

重新截一系列的图片，我认为意义也不大，我就截一张图片展现多次强刷而产生的过程

上图反映了我多次请求某个ASPX页面的过程，从图片中可以看出，只有第一次是200的响应，后面全是304，是您所期待的结果吧。

再来看看它的实现代码吧：

public partial class Demo304 : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
DateTime dt;
if( DateTime.TryParse(Request.Headers["If-Modified-Since"], out dt) ) {
// 注意：如果是20秒内，我就以304的方式响应。
if( (DateTime.Now - dt).TotalSeconds < 20.0 ) {
Response.StatusCode = 304;
Response.End();
return;
}
}

// 注意这个调用，它可以产生"Last-Modified"这个响应头，浏览器在收到这个头以后，
// 在后续对这个页面访问时，就会将时间以"If-Modified-Since"的形式发到服务器
// 这样，上面代码的判断就能生效。
Response.Cache.SetLastModified(DateTime.Now);
}
}

虽然代码并不复杂，但我还是打算来解释一下：
在浏览器第一次请求页面时，会执行SetLastModified的调用，它会在响应时输出一个"Last-Modified"这个响应头，然后，当浏览器再次访问这个页面时，会将上次请求所获取的"Last-Modified"头的内容，以"If-Modified-Since"这个请求头的形式发给服务端，此时服务器就可以根据具体逻辑来判断要不要使用304应答了。

在前面的请求图片的示例中，服务器以图片文件的最后修改时间做为"Last-Modified"发给浏览器，浏览器在后续请求那张图片时，又以"If-Modified-Since"的形式告之服务端，此时服务端只要再次检查一下这张图片就知道图片在上次访问后有没有发生修改，如果没有修改，当然就以304的形式告之浏览器：继续使用缓存版本。

还是前面的请求图片的示例，其实服务端还使用了另一对【请求/响应】头：

这二个头的使用方式是：服务端输出一个ETag头，浏览器在接收后，以If-None-Match的形式在后续请求中发送到服务端，供服务端判断是否使用304应答。

"Last-Modified"与"ETag"这二者，事实上只需要使用一个就够了，关键还是看服务端如何处理它们，浏览器只是在接收后，下次再发出去而已。

不过，前面的示例代码并没有使用缓存头，事实上，也可以带上它，这样可以尽量减少对服务器的访问，毕竟用户不会一直强刷浏览器。这二种方式虽然有较大差别，但它们绝对是可以互补的。

为了能形象的描绘缓存页（或者其它文档）的请求过程，我画了张示意图供大家参考：

如何避开HTTP缓存

前面小节中，介绍了二种方法使用浏览器的缓存。但有些时候可能反而希望浏览器能放弃它缓存的结果。现在的浏览器都有缓存功能，尤其是对一些静态文件，比如：图片，JS，CSS, HTML文件，都能缓存。但有时候我们需要更新CSS, JS文件呢，浏览器如果还使用它的缓存版本，显然就有问题了。而且有些网站使用了URL重写，使原来的动态页面扩展名也变成静态的HTML文件了，因此，仍然希望浏览器在某些时候能够不要缓存这些伪静态页面。

此时，我们就希望浏览器放弃从HTTP请求所获得的结果了。一般说来，浏览器在处理（它认为的）静态文件时，会按照URL为kEY来保存那些缓存结果，因此，通常的解决办法也就是修改URL，比如：原来是请求abc.js的，要改成abc.js?t=23434，后面要跟上一个参数，让以前的缓存不起作用。至于参数t的取值可以根据文件的最后修改时间，也可以手工指定，总之只要改变它就可以了。

但是，对于伪静态的页面，我们不能再使用这种方法了，原因就不用解释了吧。
那么，可以采用在服务端输出一个响应头，通过响应头的方式告之浏览器，不要缓存此文件。比如，可以调用这个方法：

Response.Cache.SetNoStore();

它会生成这样的响应头内容：

Cache-Control: private, no-store

许多浏览器都能识别它。还有另一种方法是设置一个已过期的过期时间。

前面所说的在URL中加额外参数的做法，在JS中也比较常用，比如 JQuery就支持让某个Ajax请求不缓存，它的方式就是设置{cache: false}，最终它便会在生成的URL中加上一个临时参数，以保证后面的请求的地址是不重复的，最终达到避开缓存的目的。JQuery的使用太简单，我就不再给出示例代码了。

点击此处下载示例代码

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

本文链接