开发笔记 第816页

• 项目名称:惠海IT商城
• 网        址:http://http://www.huihaimall.com/
• 开发环境:WinXP SP3、IIS5.0、Dreamweaver、VS 2005、SQL-Server 2000
• 项目描述:项目实现了商品的浏览筛选(主要是公司做的IT产品)、会员商品收藏、订购(订单)、发邮件推荐给朋友、会员积分、收货地址薄、DIY自主装机等,业务逻辑全部在本项目中用.NET(CMP)实现,而展示就不一定都是用.net的aspx页面来做,如DIY装机就是用Flex生成flash来实现的,但是它们都是同步的(同登陆同注销,包括会员产品收藏等).还有一个最重要的就是后台管理也是用Flex调用.net来实现的,由于要提供Flex调用的接口,所有还提供了几个WebService的页面(关与身份验证请见:在WebService中使用Session或Cookie—实现WebService身份验证(客户端是Flex) ),另外在用JQuery发送Ajax请求的时候页面传输数据时候还有用到Json数据(Flex好象有几个地方也用到了).
• 项目解决方案截图如下:
  
  下面,我对上图所示以我的了解进行简要的介绍:

• 下面来说一下Web.Config文件的相关配置
• 在configuration下的configSections的第一个子节点,配置CMP读取的自定义节点
  <section name="GWConfig" type="Huihai.Mall.CMPServices.CMPConfigurationHandler, Huihai.Mall.CMPServices" />
• 再在configSections下增加CMP跟踪监视等级及数据库连接字符串,默认本地日志文件路径等配置(以下为我项目里面的一些CMP配置,最下面的为商城的一些配置)
  <system.diagnostics>
  <switches>
  <add name="GWTrace" value="4" />
  </switches>
  </system.diagnostics>
  <appSettings>
  <add key="ErrorViewUrlPrefix" value="/Wawacrm/ErrorLog/" />
  <add key="ErrorLogBaseDir" value="E:\me\bak\oa\WAWACRM\Errors\" />
  <add key="DefaultDataSource" value="server=127.0.0.1;database=HH_System;uid=sa;pwd=123" />
  <add key="picurl" value="Upload/product/" />
  <add key="score" value="1" />
  <add key="isShowRunTime" value="true" />
  <!– 产品评论 –>
  <add key="CommentIsAudit" value="Y" />
  <!– 产品评论回复 –>
  <add key="ReCommentIsAudit" value="Y" />
  <!– 产品咨询 –>
  <add key="ConsultIsAudit" value="N" />
  <!– 商城咨询反馈 –>
  <add key="FeedbackIsAudit" value="Y" />
  <!– 后台管理员的使用的邮箱名后缀 –>
  <add key="EmailPostfix" value="@coreoa.cn" />
  </appSettings>
• 接 下来最重要的也是最复杂的就是GWConfig自定义CMP元数据配置的节点了, 它里面主要是配置每一个存储过程,对应容易实体类,及该业务实体的Insert、Update、Delete、Select四个方法的参数的详细描述,已 上面MallMemberDAL项目的Address和Coupon为例,它的配置为如下:
  <GWConfig>
  <ContainerMappingSet>
  <ContainerMapping>
  <ContainerMappingId>Address</ContainerMappingId>
  <ContainedClass>AddressItem</ContainedClass>
  <Insert>
  <CommandName>MO_Address_Insert</CommandName>
  <Parameter>
  <ClassMember>Member_inner_code</ClassMember>
  <ParameterName>@member_inner_code</ParameterName>
  <DbTypeHint>Int</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>4</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Province</ClassMember>
  <ParameterName>@province</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>20</Size>
  </Parameter>
  <Parameter>
  <ClassMember>City</ClassMember>
  <ParameterName>@city</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>20</Size>
  </Parameter>
  <Parameter>
  <ClassMember>County</ClassMember>
  <ParameterName>@county</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>20</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Zip</ClassMember>
  <ParameterName>@zip</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>6</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Address</ClassMember>
  <ParameterName>@address</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>100</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Name</ClassMember>
  <ParameterName>@name</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>50</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Mobile</ClassMember>
  <ParameterName>@mobile</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>15</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Tel</ClassMember>
  <ParameterName>@tel</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>50</Size>
  </Parameter>
  <Parameter>
  <ClassMember>IsDefault</ClassMember>
  <ParameterName>@isDefault</ParameterName>
  <DbTypeHint>Char</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>1</Size>
  </Parameter>
  </Insert>
  </ContainerMapping>
  <ContainerMapping>
  <ContainerMappingId>Coupon</ContainerMappingId>
  <ContainedClass>CouponItem</ContainedClass>
  <Select>
  <CommandName>MO_Coupon_Select</CommandName>
  <Parameter>
  <ClassMember>Sn</ClassMember>
  <ParameterName>@sn</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>10</Size>
  </Parameter>
  <Parameter>
  <ClassMember>Password</ClassMember>
  <ParameterName>@password</ParameterName>
  <DbTypeHint>Varchar</DbTypeHint>
  <ParamDirection>Input</ParamDirection>
  <Size>10</Size>
  </Parameter>
  </Select>
  </ContainerMapping>
  </ContainerMappingSet>
  </GWConfig>
• 以 上配置中,为简便示例Address只有配置Insert的方法,它调用名为MO_Address_Insert的存储过程,Insert节点下第一个子 节点CommandName即为存储过程名,而同级别的还有Parameter节点,每一个都代表存储过程的一个参数,下面有ClassMember、 ParamDirection等子节点即是对它的描述,其他Update、Delete、Select依此类推也可以按这种格式来配置;而Coupon只 有配置一个Select的节点(其他的也能按照上述增加配置,没有配置的方法将不能调用),Coupon是为ContainerMappingId容器业 务实体唯一Key,它对应名为CouponItem的业务实体模型类,而参数下面的ClassMember为实体下的成员名,一般就是实体类的属性,因为 它将根据这个名字反射获得实体的属性值.以上这么多配置但是却只实现了2个业务的方法,是不是有点太麻烦了?没得办法,最开始的CMP模式就是这样一个个 把存储过程配置好的!但是你的项目里面要用到的存储过程肯定不只与2个,姑且就不说CMP模式这样配置也只能用存储过程的,但是存储过程一多了就会很麻烦 了,每一个存储过程配置都要手写添家进去!要是存储过程上十来个参数又有增删改查的方法岂不要配置很多东西?的确要配置的东西不少,但是我们可以自己写的 小程序对CMP的配置执行操作,而不需要我们去打开Web.Config文件一个个去手改,下图为我自己写的一个对CMP的配置进行操作的截图:
• 
• 上 面主要是通过XPath表达试对Web.Config进行筛选读取CMP的配置节点并在GridView里面显示出来,并能直接对其进行修改等操作.如果 假如我们要增加一个的时候,我们可以点浏览用sysobjects把数据库里面所有的存储过程名字等信息读出来,选择要配置的那个存储过程后再用 sp_sproc_columns把它所有的参数信息读出来,如ParameterName、Size、ParamDirection等,注意 ClassMember(实体模型的属性名)读出来默认是ParameterName,因为在我的项目里面ParameterName名就跟实体的属性名 一样,你也可以改成其他的,但是你要根据你实体命名的约定好,因为它要用反射实体里找这个属性,如果找不到就不好了.
• 是 不是用上面那个小工具爽多了?你不需要打开Web.Config手写一个配置,在数据库里面写一个存储过程就到这里配置一下直接在增加一个CMP的配置节 点到Web.Config文件内.,我这个商城的项目下来把所有业务的存储过程配置完Web.Config文件总大小有140KB,把 Web.Config文件撑得这么大对性能会不会有影响呢?我想应该不会有多大影响的,从CMP框架的运行来看,它只是在 Application_Start的时候读取一次配置文件到内存,以后就像读AppSettings一样直接在内存里面取,很方便 的.Application_Start运行的代码如下:
• // 在应用程序启动时运行
  System.Configuration.ConfigurationManager.GetSection("GWConfig");
  SiteProfile.DefaultDataSource = System.Configuration.ConfigurationManager.AppSettings["DefaultDataSource"];
  SiteProfile.DbTypeHints["Varchar"] = System.Data.SqlDbType.VarChar;
  SiteProfile.DbTypeHints["Nvarchar"] = System.Data.SqlDbType.NVarChar;
  SiteProfile.DbTypeHints["Int"] = System.Data.SqlDbType.Int;
  SiteProfile.DbTypeHints["Date"] = System.Data.SqlDbType.DateTime;
  SiteProfile.DbTypeHints["Text"] = System.Data.SqlDbType.Text;
  SiteProfile.DbTypeHints["Bit"] = System.Data.SqlDbType.Bit;
  SiteProfile.DbTypeHints["Money"] = System.Data.SqlDbType.Money;
  SiteProfile.DbTypeHints["Datetime"] = System.Data.SqlDbType.DateTime;
  //后新添加2种对应类型
  SiteProfile.DbTypeHints["Char"] = System.Data.SqlDbType.Char;
  SiteProfile.DbTypeHints["Numeric"] = System.Data.SqlDbType.Decimal;
  SiteProfile.DbTypeHints["Smalldatetime"] = System.Data.SqlDbType.SmallDateTime;
  //监听配置文件的改变
  System.IO.FileSystemWatcher fsw = new System.IO.FileSystemWatcher(Server.MapPath("~/Upload/special"));
  fsw.Filter = "XMLFile.xml";
  fsw.NotifyFilter = System.IO.NotifyFilters.LastWrite;
  fsw.Changed += new System.IO.FileSystemEventHandler(ReadAdConfig);
  fsw.EnableRaisingEvents = true;
  ReadAdConfig(null, null);
• 上 面代码主要是在程序启动的时候Web.Config的CMP配置的元数据读到CMP的一个静态类里面,初始化数据连接,设置存储过程参数对应的SQL数据 类型,后面监听和ReadAdConfig方法是我项目另外的东西,这里就不叉开话题说了. 配置搞清楚了,下面我们就来研究一下CMP这个架构到底是如何运行的呢? 还是以上面的那个例子为准,比如我要在Address里增加一个会员收货地址.我就在AddressManager里面提供一个 AddressInsert的静态方法供调用.
• public static void AddressInsert(AddressItem item)
  {
  SqlPersistenceContainer spc = new SqlPersistenceContainer(CMPConfigurationHandler.ContainerMaps["Address"]);
  spc.Insert(item);
  }
• 上面所示为CMP一个调用业务的过程,它实现的全过程大概为:
• ①第一步: 在Application_Start把CMP的所有配置读取到CMPConfigurationHandler下面的ContainerMaps集合里面,它是一个Hashtable对象
• ②第二步: 根据Address这个ContainerMappingId的key在CMPConfigurationHandler.ContainerMaps匹配到Address这个业务对象的ContainerMapping映射容器对象
• ③第三步: 实例化SqlPersistenceContainer托管容器对象,ContainerMapping作为构造函数穿入,并使用: base(initCurrentMap)调用StdPersistenceContainer父类构造函数
• ④第四步: 执行具体方法(这里为Insert操作),而参数为继承了PersistableObject类型的实体模型对象,为了更好的说明我也把Insert方法的代码给帖出来
• /// <summary>
  ///
  /// </summary>
  /// <param name="insertObject"></param>
  public override void Insert(PersistableObject insertObject)
  {
  GWTrace.EnteringMethod(MethodBase.GetCurrentMethod());
  try
  {
  CommandMapping cmdMap = currentMap.InsertCommand;
  SqlCommand insertCommand = BuildCommandFromMapping(cmdMap);
  AssignValuesToParameters(cmdMap, ref insertCommand, insertObject);
  insertCommand.Connection.Open();
  insertCommand.ExecuteNonQuery();
  insertCommand.Connection.Close();
  AssignOutputValuesToInstance(cmdMap, insertCommand, ref insertObject);
  insertCommand.Dispose();
  }
  catch (Exception dbException)
  {
  string s = insertObject.ToXmlString();
  s+=currentMap.InsertCommand.CommandName;
  throw new Exception("Persistance (Insert) Failed for PersistableObject", dbException);
  }
  }
• 由 于受空间限制没能把全部代码贴出来比较难看一点,大概原理是根据PersistableObject 对象(实际为保存在XML内的CMP的配置映射到的容器)和要执行的方法创建SqlCommand对象,设置它要执行的存储过程名称.再循环 Parameter创建并添加参数,再在PersistableObject 根据反射ClassMember获得实体里面的属性值设置Parameter参数值.然后在执行存储过程,并跟踪记录当前错误方法,处理异常信息,这样便 完成了CMP一个业务处理的全过程.
• 是不是感觉这样调用有点'妙' 呢?你要修改那个业务对象你只需要指定对应的实体模型的属性值它就能作为参数Insert(Update或Delete)数据库表里面对应的列,如果存储 过程参数对应的实体属性值没有指定的话将传递的为默认值,如String类型的将为NULL.这里在反射的时候还要注意一个问题,就是列为时间类型的时 候,C#里面的DataTime为空的时候为初始值为0001-1-1 0:00:00,而当你使用反射的时候把这个时间更新到数据库会报错,提示什么数据溢出,因为SQL里时间类型是有一个时间段,所以在CMP调用 AssignValuesToParameters方法使用发射赋值的时候要加上一个判断,这样修改时间类型字段指定为空就没有问题了.
• object o = PropertyInfo.GetValue(persistObject, null);
  if (o == null)
  o = DBNull.Value;
  if (o.GetType().Equals(typeof(System.DateTime)))
  {
  //时间默认值(即未给时间赋值),则为空
  if (o.ToString() == "0001-1-1 0:00:00")
  o = DBNull.Value;
  }
  
• 而 Select查询操作略有一点不同, 因为它要返回结果解,这个时候就应该要用AddressSet类了,所有要实现查询操作的类都必须继承自PersistableObjectSet,因为 它能有返回DataSet数据集的实现,可以把它看成一个特殊的PersistableObject对象,因为它除开有Insert、Delete、 Update还有Select.AddressSet类其实也是一个实体类,但它跟AddressItem类不同的是它只管查询,而查询的存储过程往往没 有增、删、改的那么多的参数,因此它的里面只需要几个查询条件字段的属性.调用起来跟增、删、改的操作都差不多,也是根据反射它里面的属性值在赋个对应的 参数在执行,CMP默认返回的一个DataSet,我的觉得既然用到的实体,为什么不用它来代替DataSet呢?所以我在原来的基础上新加一个用反射把 DataSet转换成实体的数组,方便再次操作,代码如下:
• /// <summary>
  /// 根据引用传来的Object实体对象使用反射给它的属性赋值
  /// </summary>
  /// <param name="obj">实体对象</param>
  /// <returns>是否给表里面的记录值填充实体里属性成功,如何找不到实体属性或记录集为空返回false</returns>
  public bool ResultSingleObject(ref Object obj)
  {
  //internalData是本类里返回的DataSet集合
  if (internalData.Tables.Count == 0)
  return false;
  DataTable tab = internalData.Tables[0];
  if (tab.Rows.Count == 0)
  return false;
  Type type = obj.GetType();
  foreach (DataColumn column in tab.Columns)
  {
  string columnName = column.ColumnName;
  object t = tab.Rows[0][columnName];
  PropertyInfo property = type.GetProperty(columnName);
  if (property == null)
  property = type.GetProperty(columnName.Substring(0, 1).ToUpper() + columnName.Substring(1, columnName.Length – 1));
  if (property == null)
  property = type.GetProperty(columnName.ToUpper());
  if (property != null)
  {
  if (t.GetType().FullName != "System.DBNull")//如果数据库返回的值不等于NULL的情况下才给找到了实体的字段属性赋值
  property.SetValue(obj, t, null);
  }
  else
  throw new Exception("表的列名为" + columnName + "不能与实体名为" + type.Name + "的属性名一致,请修改过程的返回的列名称或实体属性名");//便与调试
  }
  return true;
  }
• 通过如上代码for循环一下就能把DataSet转换成AddressItem数组或是List<AddressItem>泛型.
• CMP模式差不多就这么多些吧,总结其中一些美中不足的地方:
• Insert、 Delete、Update、Select这个四个方法还不能满足需求,增删改查这个四个方法是CMP的核心,但一个业务实体的操作只有这个4个方法往往 是不够的.因为这四个方法只能分别对应一个储存过程,而查询的存储过程一般一个难得搞定,比如用户表我除开根据用户ID去查询,还要根据用户名和密码,还 有可能要根据用户类型返回用户列表等等,实际的需求是复杂的.用CMP的话那我还需要另外单独配置2个业务实体来分别放根据用户名和密码和根据用户类型的 操作的存储过程,而它们里面的Select都只有一个且对应的实体也是同一个,是不是感觉有点浪费?感觉Insert、Delete、Update、 Select这个四个方法不够用,后来想到增加一个List的方法,基本上每一个表都有一个根据ID去查询记录的时候,Select就对应这个操作,而新 加的List就对应根据其他条件可能会返回多条记录的操作,这样就不需要当一个业务有2个查询操作的时候而再去新建一个了,但是新增一个List查询的方 法Web.Config内CMP配置文件也要加List节点的配置,而且CMP的基类里面也要增加一个List方法并要解析对应的List配置节点,由于 当时项目做得快差不多了,这人一懒呢就没有去完成了.-_-!!!
• 连 续写了几个晚上终于快要完了,之所以我要写这些,是感觉自己最近好象都没做什么东西一样,白天在慢悠悠的上一天班,晚上就什么也不想动了,一坐到电脑前就 是看玩传奇世界或是看电视连续剧斗牛要不要、篮球火等啊,呵呵,等来得急看时间的时候已经凌晨过后了…第二天起来到公司上班,晚上又继续,我心是想我 不要每天就这样过去了,但是这样持续了好久一段时间…我有时候也自责自己到最后还是一事无成!既然来到了这行,就一定要做好这个职业的本职工作,IT 行业这个技术每天都在不断更新演变的领域你每天不去学习怎么能行呢?所以我不要再那么在'堕落'下去了,呵呵^_^,便决定写点东西,至少别自己做过的项 目都不记得去了.
• 源代码就不要问了,放在公司的SVN服务器里面了,这里提供一个我原来的参考的CMP架构的源代码下载, 好象还是蛙蛙池塘2005年写的.
• CMP模式参考源代码下载

ASP.NET applications run with a fixed-size thread pool. By default, they have 200 (or 250? I forget…) threads available to handle requests. You can make the thread pool bigger if you want, but it’s not usually helpful: more contention and overhead from thread switching will eventually actually reduce the server’s throughput. But what if most of your threads are actually sitting around doing nothing, because they’re actually waiting for some external I/O operation to complete, such as a database query or a call to an external web service? Surely things could be more efficient…

Well yes, actually. Ever since Windows NT 4 we’ve had a notion of I/O Completion Ports (IOCP) which are a mechanism for waiting for I/O to complete without causing thread contention in the meantime. .NET has a special thread pool reserved for threads waiting on IOCP, and you can take advantage of that in your ASP.NET MVC application.

The IHttpAsyncHandler, first introduced in ASP.NET 2.0, splits request processing into two. Instead of handling an entire request in one thread (expensive I/O and all), it first does some processing in the normal ASP.NET thread pool, as per any normal request, then when it’s time for I/O, it transfers control to the I/O thread, releasing the original ASP.NET thread to get on with other requests. When the I/O signals completion (via IOCP), ASP.NET claims another, possibly different thread from its worker pool to finish off the request. Thus, the ASP.NET thread pool doesn’t get ‘clogged up’ with threads that are actually just waiting for I/O.

Adding asynchronous processing to ASP.NET MVC

The MVC framework doesn’t (yet) come with any built-in support for asynchronous requests. But it’s a very extensible framework, so we can add support quite easily. First, we define AsyncController:

public class AsyncController : Controller
{
internal AsyncCallback Callback { get; set; }
internal IAsyncResult Result { get; set; }
internal Action<IAsyncResult> OnCompletion { get; set; }
 
protected void RegisterAsyncTask(Func<AsyncCallback, IAsyncResult> beginInvoke, Action<IAsyncResult> endInvoke)
{
OnCompletion = endInvoke;
Result = beginInvoke(Callback);
}
}

It’s just like a normal Controller, except it manages some internal state to do with asynchronous processing, and has the RegisterAsyncTask() method that lets you manage transitions across the gap between the two halves of IHttpAsyncHandler processing. Note: it doesn’t implement IHttpAsyncHandler itself; that’s the job of the IRouteHandler we have to set up. Unfortunately I had to reproduce most of the code from the framework’s MvcHandler, because I couldn’t just override any individual method and still get at the controller:

public class AsyncMvcRouteHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
return new AsyncMvcHandler(requestContext);
}
 
class AsyncMvcHandler : IHttpAsyncHandler, IRequiresSessionState
{
RequestContext requestContext;
AsyncController asyncController;
HttpContext httpContext;
 
public AsyncMvcHandler(RequestContext context)
{
requestContext = context;
}
 
// IHttpHandler members
public bool IsReusable { get { return false; } }
public void ProcessRequest(HttpContext httpContext) { throw new NotImplementedException(); }
 
// IHttpAsyncHandler members
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
// Get the controller type
string controllerName = requestContext.RouteData.GetRequiredString("controller");
 
// Obtain an instance of the controller
IControllerFactory factory = ControllerBuilder.Current.GetControllerFactory();
IController controller = factory.CreateController(requestContext, controllerName);
if (controller == null)
throw new InvalidOperationException("Can't locate the controller " + controllerName);
try
{
asyncController = controller as AsyncController;
if (asyncController == null)
throw new InvalidOperationException("Controller isn't an AsyncController.");
 
// Set up asynchronous processing
httpContext = HttpContext.Current; // Save this for later
asyncController.Callback = cb;
(asyncController as IController).Execute(new ControllerContext(requestContext, controller));
return asyncController.Result;
}
finally
{
factory.DisposeController(controller);
}
}
 
public void EndProcessRequest(IAsyncResult result)
{
CallContext.HostContext = httpContext; // So that RenderView() works
asyncController.OnCompletion(result);
}
}
}

It handles requests by supplying an AsyncMvcHandler, which implements IHttpAsyncHandler. Note that during the first half of the processing, i.e. during BeginProcessRequest(), it makes a record of the current HttpContext object. We have to restore that later, during EndProcessRequest(), because we’ll be in a new thread context by then and HttpContext will be null (and that breaks various ASP.NET facilities including WebForms view rendering).

Using AsyncController

It’s now very easy to handle a request asynchronously. Define a route using AsyncMvcRouteHandler, instead of MvcRouteHandler:

routes.Add(new Route("Default.aspx", new AsyncMvcRouteHandler())
{
Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});

Then set up an AsyncController. In this example, we’re calling an external web service using the WebRequest class and its BeginGetResponse() method. That uses an IOCP, so won’t consume an ASP.NET worker thread while it waits:

public class HomeController : AsyncController
{
public void Index()
{
WebRequest req = WebRequest.Create("http://www.example.com");
req.Method = "GET";
 
RegisterAsyncTask(cb => req.BeginGetResponse(cb, null), delegate(IAsyncResult result) {
WebResponse response = req.EndGetResponse(result);
// Do something with the response here if you want
RenderView("Index");
});
}
}

And that’s it. The web request gets set up and started in the first half of the async processing model, then the thread gets released to serve other requests. When the web request signals completion, ASP.NET takes a different thread from its pool, and gets it to run the code inside the anonymous delegate, inheriting the request context from the first thread so it can send output to the visitor.

Just remember that you should only use async requests when you’re waiting for some operation on an IOCP. Don’t use it if you just going to call one of your own delegates asynchronously (e.g. using QueueUserWorkItem()) because that will come out of the ASP.NET worker thread pool and you’ll get exactly zero benefit (but more overhead).

这次探险历程将从 MvcHandler 开始。

首 先从 RouteData 中提取 Controller 的名字(这个名字是我们在 Global.asax.cs RegisterRoutes 中注册 Route 时提供的)，然后获取 ControllerFactory，只不过这里面专门提供了一个 ControllerBuilder。

除非我们自定义 MvcHandler，否则就直接去看看这个 ControllerBuilder.Current 吧。

嗯，有点意思。剔除掉无关紧要的代码，这个 ControllerBuilder 告诉我们如下事实。
(1) 通常情况下，返回一个默认的 DefaultControllerFactory 实例。
(2) 我们可以在 Application_Start 中通过 ControllerBuilder.Current.SetControllerFactory 方法来注册一个我们自定义的工厂。
(3) 核心代码: factory = (IControllerFactory)Activator.CreateInstance(controllerFactoryType);
好 了，回到前面的流程。MvcHandler.ProcessRequest 是通过 DefaultControllerFactory.CreateController(RequestContext, requiredString) 来返回 IController 实例。那么我们就看看这个 DefaultControllerFactory.CreateController 又有什么玄机。

这 个实在没啥好说的，通过反射来创建 Controller 实例。唯一有点看头的就是 GetControllerType 里面做了些缓存处理，以此来避免频繁使用反射造成的性能问题。回到 MvcHandler.ProcessRequest()，在得到控制器实例后，MvcHandler 开始了调用 Controller.Execute() 来进一步触发后续操作，同时对其上下文进一步封装，除了前面创建的 RequestContext，还加上了当前这个 Controller 对象的引用。

获取 Action 的名字，然后开始执行 InvokeAction。

这 段代码还是很有趣的。首先，它通过反射获取所有同名 Action 方法信息；其次，它过滤掉所有有 NonActionAttribute 和 IsSpecialName 标记的方法；第三，当同名有效 Action 被重载时它会抛出异常 —— 提示 "Controller_MoreThanOneAction"。
也就是说下面的写法是可以的。

可一旦去掉那个 "[NonAction]"，你将看到如下的异常信息。

继续 InvokeActionMethod，这个方法看上去很复杂，其实最核心的代码就最后一行，前面都是相关参数的分解。

这行代码将 Action 的调用作为一个委托，连同反射信息传递给 InvokeActionMethodFilters。

这 个方法首先将默认的过滤器 ControllerActionFilter 加到列表，然后提取所有继承层次上基类的过滤器特性。最后将这些过滤器集合、过滤上下文，连同前一个方法传递进来的 Action 执行委托(continuation) 再次转交给了一个 ActionFilterExecutor 对象实例，并调用其 Execute 方法。

ExecuteRecursive 看上去不大容易理解。不过对于习惯使用递归的人来说，也不是什么难事。
(1) 通过迭代器 MoveNext() 方法提取一个过滤器对象，执行其 OnActionExecuting 方法。
(2) 如果该方法设置了 filterContext.Cancel = true，则放弃后续执行代码。这种机制为我们提供了更好的控制(Preview 1 通过 Context.OnPreAction 的返回值来做同样的控制，现已废弃)，比如写一个 CacheFilterAttribute，在缓存未过期时直接输出静态内容，并终止后续执行。(我会在后面章节，提供一个可用的缓存过滤器代码)
(3) 进入第 16 行递归调用，这样一来，就可以一层一层调用所有的 ActionFilterAttribute.OnActionExecuting 方法，直到 MoveNext() == false。
(4) 在最后一次递归调用时，由于 enumerator.MoveNext() == false，故 36 行的 _continuation() 方法得以被执行。还记得这个方法吗？就是前面给传递过来的 Action 方法委托，这意味着我们写的 Action 方法总算是执行了。这个方法是我们这一章流程分析的终点。
(5) 在 Action 委托执行完成后，递归调用自 29 行恢复，逐级往上回溯，直到最初那个方法堆栈。这样所有 ActionFilterAttribute.OnActionExecuted 也被执行完成。
好了，到此为止，我们基本完成了 "核心" 部分的流程分析过程。虽然简单了些，但对于我们理解 ASP.NET MVC 执行机制和原理还是很有必要的。下一章的分析，就得从那个 Action Delegate 开始了。
—————–
附: 流程分析图

查看大图

   （5）选择“Debugging->Symbols”页，然后设置符号下载URL和缓存位置。设置为：http://referencesource.microsoft.com/symbols 。
   （6）设置符号的本地缓存位置。如：C:\temp\symbols。注意确保你的Windows账户能读写这个位置。
   （7）打开“Search the above locations only when symbols are loaded manually”选项。表明只有当symbols被手动加载得情况下才使用。在这种模式下，第一次进入需要进入.NET Framework中的某一个dll时，需要手动执行Load Symbols操作（注：每个dll只有一次，之后它就被缓存到(6)所设置的本地缓存中了）。如果嫌麻烦，这里也提供了一个简单的方法，即勾选“Load symbols using the updated setting when this dialog is closed”，表明当这个设置窗口关闭的时候，立即下载所有的symbols（这将需要几分钟~几十分钟，根据网速决定），这样就不用以后再手动Load symbols操作了。

    通过以上的设置后，在调试程序的时候就可以进入框架的源代码了。通过例子看一下，创建这个工程，并设置个断点。运行程序到断点停止时，到调用堆栈窗口 (CTRL+ALT+C)右键单击一个dll(如：System.Windows.Forms.dll)，然后选择“Load Symbols”，这样会给System.Windows.Forms程序集加载符号。注意：如果在配置过程中采用了当时一次性下载了所有的 symbols的话，这里的Load Symbols可以省略不做。

    现在可以查看代码了。你可以Step In(F11)上面的的代码行，在第一次进入代码的时候，我们会显示EULA，点击ACCEPT，然后这个源代码就会下载下来，可以调试.net框架源代码了。

 

MVC 通过在 web.config 中添加相应的 Module 来参与 ASP.NET 执行流程。

那么，这个 UrlRoutingModule 自然就是我们分析过程的入口。

订阅了两个 HttpApplication 事件~~~~ 嗯，PostResolveRequestCache 要比 PostMapRequestHandler 更早执行，先从它开始吧。

首先从 RouteCollection 中获取一个 RouteData 对象，RouteCollection 何许人也？

说白了，所谓 RouteCollection 就是我们在 Global.asax.cs 中添加的 Route 集合。

回 到上文，在获取 RoteCollection 之后，通过调用 GetRouteData(context) 返回一个 RouteData 对象(详细代码可阅读 Route.GetRouteData 方法，它通过分析当前上下文的相关请求参数，返回所需的结果对象)，该对象内部包含了我们注册 Route 时的相关设置，当然就有下面所需要的 —— MvcRouteHandler。
接下来，该方法将 routeData 和上下文一起打包成 RequestContext，这应该是给后面相关处理准备的上下文环境。通过调用 MvcRouteHandler.GetHttpHandler() 方法，我们终于看到了曙光，也就是进行后续流程的关键 —— MvcHandler (有关 MvcHandler 的细节，后续章节再说)。

到了这一步，MVC 框架已经准备好了相应的执行场景，接下来就是修改默认的执行流程了。当然，辛苦得来的 "环境" 要选择一个合适的 "人"，存储到一个合适的 "地方"。

而 后的某个时间，OnApplicationPostMapRequestHandler 被执行。在 PostMapRequestHandler 中，它提取了前面预先 "埋" 下的 "坏蛋"，并修改了 HttpContext.Handler，使得 MvcHandler 能继续未完的 "事业"。至于跳转之类的，就无需我再多说。

待续……
—————————-
附上流程分析图

查看大图

ASP.NET MVC beta 模板(Templates) 中文修正补丁 完整版

2008年10月15日 发布的 ASP.NET MVC beta ，安装后，在VS2008中模板(Template)没有正确显示。

此补丁解决此问题。方便一起学习ASP.NET MVC 的朋友~

需要安装新版本，或者 需要卸载 ASP.NET MVC beta 请先使用恢复功能！~

2008年12月28日 补充：

非常抱歉，做了一件事却没有认真去做好。之前上传了一份补丁，却只修正了C#的部分模板。

这次重新发布了此补丁，可以修正C# VB 及Test 的模板~ 希望能给大家带来方便~！

下载：ASP.NET MVC beta 模板(Templates) 中文修正补丁 完整版

我们先了解一下 System.Web.Routing 中的几个类型。

• UrlRoutingModule : IHttpModule : 入口点。订阅 HttpApplication 相关事件，修改 HttpContext.Handler (IHttpHandler)，使得 MvcHandler 得以执行。
• Route : RouteBase : 路径转向规则，包括路径匹配表达式(Url)、参数默认值(Defaults)、请求处理程序(RouteHandler) 等。
• RouteCollection : Collection<RouteBase> : 存储所有的 Route 规则的集合，提供依据上下文获取动态路由数据的方法。
• RouteTable : 持有全局 RouteCollection 实例引用的一个辅助类。
• RouteData : 依据当前上下文进行解析的动态请求路由信息，包括从请求参数或路由规则中提取的 Controller Name、Action Name、Action Method Parameter 等。
• IRouteHandler : Route 中请求处理程序的包装接口。

要使用 Routing，除了在配置文件中添加 UrlRoutingModule 外，我们还得在 Global.asax.cs 中注册相应的路由规则(Route)。

System.Web.Mvc 额外提供了几个扩展方法来简化我们注册 Route 规则。

有一点需要注意，System.Web.Routing 通过循环查找的方式来匹配路由规则，因为我们要按以下顺序注册路由规则。
(1) 忽略规则 (IgnoreRoute)。
(2) 具体匹配规则。
(3) 通用匹配规则。
RouteTable.Routes 实际上指向一个应用程序域中唯一的 RouteCollection 实例。

RouteCollection 除了保存所有路由规则 (Route) 外，还有几个重要的方法。

GetRouteData() 通过当前请求上下文，找出最合适的路由规则(Route)，并生成当前执行环境所需的动态路由数据(RouteData)。

循环调用搜索规则的 GetRouteData 方法来获取动态路由数据，这就是上面我们提到要注意路由规则注册顺序的原因。

Route.GetRouteData() 首先调用 ParsedRoute.Match() 来检查路径是否匹配，接下来使用 ProcessConstraints() 检查相应的约束规则，如果这些检查都得以通过，则生成最终的动态路由数据。RouteCollection.GetRouteData() 在获取该结果后终止循环。
IRouteHandler 的作用是返回一个特定 IHttpHandler，比如 MvcHandler，当然也可以是 "System.Web.UI.Page : IHttpHandler"。

UrlRoutingModule 的执行顺序，可参考《ASP.NET MVC Preview 2 – 流程分析 (1)》。
Route 的相关语法规则，可参考《ASP.NET MVC Preview 3 Release 》(ScottGu 中文版)。

P3 改用一堆继承自 ActionResult 的对象来完成视图显示，这是该版本的最大变化。
1. ViewResult
当 我们在 Action Method 中调用 View 生成 ViewResult 的时候，应该注意两个细节，那就是生成默认的 ViewData 字典和 WebFormViewEngine 视图显示引擎。上一节的分析中我们已经知道 ActionFilter.OnActionExecuting 在 Action Method 之前执行，那么我们完全可以定义一个自己的视图引擎，比如用 NVelocity 来代替 WebForm。(可参考《ASP.NET MVC Preview 2 – 流程分析 (3) 》和《ASP.NET MVC Preview 2 – NVelocityViewEngine 》)

在 Controller.InvokeAction() 的最后会间接通过 InvokeActionResult() 来调用 ViewResult.ExecuteResult，从而实现对视图引擎的触发 (可参考上一章)。

创建视图上下文，并调用 WebFormViewEngine.RenderView()。

这部分的变化并不大，有关细节可参考 《ASP.NET MVC Preview 2 – 流程分析 (3)》，这里就不在啰嗦了。
2. RedirectResult / RedirectToRouteResult
其实很简单，重建 RouteValueDictionary，然后在 RedirectToRouteResult.ExecuteResult() 中使用 HttpContext.Response.Redirect() 进行跳转。

尽管这种跳转会导致 Controller 实例被重新生成，但我们依然可以使用 TempData 传递相关的数据给下一个 Action。(有关 TempData 传递数据的原理，可阅读《ASP.NET MVC Preview 2 – RedirectToAction》)
下面是一个跳转的演示

在使用 Controller.RedirectToRoute 时有个参数叫 routeName，其实它就是 Global.asax.cs 中调用 MapRoute 时的定义。

3. JsonResult
有了这个，写 Ajax 操作就简单多了。

写个例子看看。

看看返回的 Http 结果。

4. ContentResult
这个纯粹就是代码缩写了，将 "Response.Write(…)" 简写成 "Content(…)"。

5. EmptyResult
这个最好，没啥可说，没啥可做。

唯一要关注的是，ControllerActionInvoker.InvokeActionMethod 会将 Action return null 转为为 EmptyResult。

接着上一章留下的线索，我们开始分析 Controller 的执行过程。
1. Controller.Execute

熟 悉的面孔 —— TempData。和 ViewData 的目标不同，TempData 主要用于 Controller 内部的数据传递。从 Router 字典中取出 Action 的名字，并创建一个专门的 Invoker 来完成整个执行工作，包括过滤器(ActionFilterAttribute)、Action Method，以及视图显示(IViewDataContainer)。MVC 给了我们一个选择，我们可以继承并创建一个自定义的 Invoker 去改变一些内在的规则 (在 Controller.ctor 中对 ActionInvoker 赋值)。
2. ControllerActionInvoker.InvokeAction
如 果你看书很仔细的话，难道你对上面 Execute 方法里面的 "invoker.InvokeAction(actionName, new Dictionary<string, object>())" 语句不感到奇怪吗？一个没有任何引用的空 Dictionary，这似乎不合乎情理。传递参数？返回某些值？注意看下面的分析。

FindActionMethod 方法利用反射返回 Action 方法的信息，注意 NonActionAttribute、Controller_ActionCannotBeGeneric。很显然这个作者有非常好的编码习惯，代码注 释非常清晰有用，值得学习。可以有和 Action 签名相同的重载方法，但必须加上 NonActionAttribute 特性。同时 Action 不能是泛型方法。

GetParameterValues 方法的作用是从环境上下文中获取 Action 方法执行所需的参数 (Argument)。比如 Action 的方法签名是 "public ActionResult Test(int x, int y)"，那么 GetParameterValues 则必须返回一个类似 "{{x, 123}, {y, 456 }}" 这样的参数字典，在反射调用 Test 时，传递过去。

循环提取所有的 ParameterInfo，不过这里有了另外一个限制，那就是方法参数不能使用 ref / out 关键字。GetParameterValue 方法应该是获取具体参数值，一路传递过来的那个空字典被丢了进去。

再次夸一下作者，那几行注释说明了一切。对于 Action 方法参数的获取，有三种优先级不同的方式：
1. 从调用 InvokeAction 传递进来的参数字典中提取。(就是那个莫名其妙的字典，这意味着自定义 Invoker 有机会对请求参数做出调整)
2. 从 RouteData 中查找，这有两种可能：第一是 URL 请求中已有的参数；其次就是 routes.MapRoute 定义的缺省值。
3. 如果上述两个方法都没有找到参数值，那只好从 Request 中提取了。(某些时候，MapRoute 的定义并不完整，尤其是 {Controller}/{Action} 这种通用规则)
在准备好 Action 的相关数据后，InvokeAction 调用 GetAllActionFilters 获取所有的过滤器。

这个方法看上去有点复杂。
1. 创建一个后进先出的栈。
2. 将 Action 压进去。
3. 循环向上查找所有级别的 Base Type，并将 Base Action Method 压到栈里。
4. 接下来将当前 Controller Type 以及其所有 Base Type 先后压到栈里。
5. 创建一个列表用于存储实际的 IActionFilter 集合。
6. 将当前 Controller 添加到列表，别忘了默认情况下控制器本身也实现了 IActionFilter。
7. 使用循环依次从栈中弹出 Base Type、Base Action Method 以及 Current Action Method，并调用 GetActionFiltersForMember 获取其所有 ActionFilterAttribute 定义。
8. 返回一个过滤器列表。(由于是后进先出的栈，因此列表内部顺序是：Current Controller、Base Type Filter、Base Action Method Filter、Current Action Method Filter)
注意 ActionFilterAttribute 是可以应用的 Class 上的，也就是说对所有的 Action 方法都有效。现在你该理解上面获取基类型的原因了吧。

当然，我们还是要看看 GetActionFiltersForMember。

这 个方法很简单，用反射查找 ActinFilterAttribute。唯一需要注意的是 order 这个排序属性，返回的列表是按此属性排序过的。ActionFilterAttribute.Order 默认等于 -1，也就说不修改这个排序属性的话，会按照其定义顺序返回。另外还有一个需要注意的地方，如果 ActionFilterAttribute.Order > 0，那么多个 Filter.Order 不能相同，否则会抛出类似下面这样的异常。

回到正题，InvokeAction 获得全部 Filter 后，InvokeActionMethodWithFilters 被调用。

将 Action Method 用委托进行包装，反转过滤器列表进行集合累计调用。Aggregate + InvokeActionMethodFilter 通过递归调用完成 Filter OnActionExecuting -> Current Action Execute -> Filter OnActionExecuted 这样一个执行过程。下面是调用结果示例。

InvokeAction 紧接着会通过调用 InvokeActionResultWithFilters 完成对 Filter.OnResultExecuting 和 OnResultExecuted 的调用，这是 P2 所没有的。
InvokeActionResultWithFilters 和 InvokeActionMethodWithFilters 过程差不多，都是递归调用。需要特别注意的是 InvokeActionResult 代替了 InvokeActionMethod。(注意：尽管 BaseController 本身也是一个 ActionFilterAttribute，但并不会被调用)

执行结果顺序演示：

我们看看 InvokeActionResult 做了些什么。

调 用 ActionResult.ExecuteResult 方法？有什么作用呢？如果你已经看过 P3 的帮助文件的话，你应该知道 Action Method 可以通过 Controller.View()、Controller.Json()、Controller.RedirectToRouteResult() 方法返回如下几种 ActionResult。

先不管后面两种，看看 ViewResult.ExecuteResult() 会做什么？

HoHo~~~~ 终于看到了视图显示的曙光了，不过这属于下一篇的内容。
———————–
ControllerActionInvoker.InvokeAction()、Controller.Execute() 执行至此结束。
执行流程图

查看大图

System.Web.Routing已经作为一个程序集包含在.net3.5sp1中发布了。虽然我们并没有在3.5sp1中发现ASP.NET Mvc的踪迹，但是亦以感觉到它离我们不远了。

System.Web.Routing用于在ASP.NET的Web应用程序中进行URLRouting。

所谓UrlRouting就是将一个地址映射为另一个地址，比如我访问/chsword/2008/08/27.html其实是访问了 /chsword/article.aspx?y=2008&m=08&d=27这个地址，URLRouting使我们的URL看起来非 常漂亮。

本文将分２部分介绍UrlRouting的使用分别为入门篇与进阶篇。

文章的前提：

1.         安装Visual Studio 2008 sp1或其它IDE的等同版本。

2.         建立一个Asp.net Web Application（Asp.net Web应用程序）

3.         引用System.Web.Routing程序集。

UrlRouting的实现原理

如果你不是追求理论的人，仅仅是务实主义，可以直接从准备工作读起。

为了方便大家理解我绘制了一个UML图，其中通过RouteTable的Routes这个属性可以获取一个RouteCollection的Singleton模式，虽然在其中并没有判断值不存在时才初始化的Singleton的标志性行为，但是它是在Application_Start事件中进行初始化的，并且直到应用程序进程终结，所以是Singleton模式的。

而通过以下方式将Route添加到RouteTable.Routes中

RouteTable.Routes.Add(new Route());

以上代码仅为表示其流程，这个代码是不能正确执行的，因为Route没有提供无参构造函数。

Route初始化时则是利用RouteValueDictionary来加入默认值及规则到Route中

另外Route还有一个IRouteHandler的实现对象，IRouteHandler的实现对象提供了一个GetHttpHandler方法来获取用于处理URL的IHttpHandler。

这么说还是停留在抽象层次的，下面我们以一些简单例子来带你驭起UrlRouting。

准备工作

由于须要一个处理Url的IHttpHandler所以我们先定义一个实现了IHttpHandler接口的类。

就叫它MyPage，由于我们要与IRouteHandler交互，所以除了实现IHttpHandler的方法之外还要声明一个RequestContext类型的属性。

这样我们就拥有了一个自己的IHttpHandler。

下面我们实现一个IRouteHandler：

这里实现了IRouteHandler的GetHttpHandler方法，使之返回刚才我们实现的MyPage。

这样我们前期的２个工作就做完了，我们可以来实现UrlRouting了。

实现第一个UrlRouting

其实UrlRouting在定义完上两个规则后就很简单了。

在Golbal.asax（没有可以新建一个）的Application_Start事件中写如下代码

这样我们就定义了第一个UrlRouting规则就是对xxxx.aspx这类的Url进行Routing。

但是我们仅仅是定义了处理了什么样的Url，却没定义如何处理。

我们应该在刚刚定义的MyPage的ProcessRequest方法中定义如何处理。

我们将ProcessRequest方法实现如下：

很显然这里的RequestContext.RouteData.Values["page"]就是取到刚才的规则{page}.aspx中的page的值即，如果我访问index.aspx则RequestContext.RouteData.Values["page"]就是index。

我这里的定义是将”_”替换为”/”所以就是将list_index.aspx这样的URL转到list/index.aspx这样的网页上。

我们建立一些测试用的网页如下图所示：

在这些网页里随意写些可以分辨网页的文字。

则访问list_chsword.aspx时自动Routing到了list/chsword.aspx上了。

总结一下UrlRouting与以下有关：

1.         Application_Start中定义的规则

2.         自己实现的IHttpHandler类

上面介绍的是最简单的一种定义方式。当然我们可以建立更复杂的规则。其中就包括设定规则的默认值以及设定规则的正则表达式。

UrlRouting高级应用

预计效果：

 首先我建立一个Route

当然IHttpHandler的处理方式也要有所改变

为了方便查看我使用了下方法：

即/a/b.aspx是映射到Default.aspx?category=a&action=b

在Default.aspx中写如下代码：

以显示传入的参数。

如果在IIS中设置Index.aspx时就算输入/a/也会访问到/a/index.aspx，即默认的会按RouteValueDictionary中设置的值自动补全

UrlRouting使用正则表达式规则

UrlRouting在定义的时候也可以按正则的规则来进行定义。

以上代码规定了action只能是数字则访问/a/1.chs可以正常访问。

而访问/a/b.chs则会显示未找到资源。

当然这是里可以使用更高级的正则表达式。

UrlRouting的技巧

排除UrlRouting的方法：

System.Web.Routing默认提供了一个IRouteHandler－StopRoutingHandler Class，经过它处理的URL不会被做任何处理

通常使用方法如下：

routes.Add(new Route("{resource}.axd/{*pathInfo}", new StopRoutingHandler()));

RouteHandler工厂：

其实IRouteHandler可以实现一个RouteHandler的简单工厂。

 规定HTTP verbs，这里要使用System.Web.Routing中的HttpMethodConstraint

Demo程序代码下载：

 http://files.cnblogs.com/chsword/WebApplication3.rar