这些辅助方法的作用是生成一些触发AJAX更新的标签及脚本，当用户点击RenderBeginAjaxForm与RenderEndForm方法生成的tag之间的提交按钮时，网页将会向服务器端发出一个AJAX请求，而服务器端的Action并最终会通过RenderPartial方法输出一个Partial Template生成的HTML。服务器端最终输出的HTML将会被替换或添加到页面的某个元素内。这就形成了一个AJAX效果。这个解决方案从某些方面看上去很酷，尤其是生成的代码可以添加到某个元素中，而不单单是如同UpdatePanel的替换，例如Nikhil在他的例子中就使用了这个特性实现了一个添加功能。不过如果使用之前提出的原则来衡量的话，似乎这个解决方案并不十分理想。

  原因很简单，因为不够透明。

  也有评论认为，Controller中的逻辑不该根据一个请求AJAX与否而进行不同处理（Nikhil的解决方案使用RenderPartial来替代RenderView为AJAX操作进行输出），因此这个解决方案破坏了MVC的职责。我不这么认为，但是我希望能做到这一点，因为做到这一点即意味着绝对的透明。绝对透明则意味着Controller将一个应用程序是否AJAX的决定权完全交给了客户端，这点非常理想，因为AJAX完全是一个表现层的概念。ASP.NET AJAX中的UpdatePanel在这方面的表现可圈可点（虽然还远不够完美），因此我最后决定也为ASP.NET MVC开发一款类似UpdatePanel的组件。值得庆幸的是，ASP.NET MVC默认使用WebForm页面作为视图模板，在这个强大的模型之下，构建出这样一个AJAX解决方案（的原形）似乎并不十分困难。

  我将这个控件命名为MvcAjaxPanel。MvcAjaxPanel与UpdatePanel最大的区别在于后者接收的是PostBack，而前者接收的只是普通的HTTP请求。Post“Back”意味着Post过后回到了原来的Page，而ASP.NET MVC的请求往往会被引导至不同的页面。因此如何跨页面进行内容更新是MvcAjaxPanel首要解决的问题。最终我选择了为每个MvcAjaxPanel指定一个UpdateAreaID的做法。

  当页面向服务器端发出一个AJAX请求时将会附带页面中的UpdateAreaID信息，而服务器端的Action并不会意识到这一点，因此依旧按照寻常逻辑指定一个视图模版并输出HTML。不过，如果视图模板中的MvcAjaxPanel发现这个请求实际上是一个符合约定的AJAX请求（请注意，只有View组件意识到这是个请求的性质），则会使用新的方法来替换标准的输出。这时候模板就会根据客户端传递过来的UpdateAreaID，寻找页面上具有同样属性值的MvcAjaxPanel，有选择性地输出内容。在客户端就会有对应的JavaScript代码接收服务器端的数据，并且更新页面中的相应区域。

  很明显，MvcAjaxPanel的工作原理与UpdatePanel有颇多相似之处，也做到了一定程度上的透明。而且与Nikhil的解决方案相比，一个非常重要的优势就是可以一次更新页面中的多个区域——其实这也就是UpdatePanel的特性之一。而且这种对Controller透明的做法又有一个天然的特点，那就是能够轻松地在不支持AJAX的浏览器中使用传统的方式切换页面。

  服务器端的实现原理并不复杂，不过作为解决方案的另一个关键部分，如何在客户端触发一个AJAX提交也是一个值得思考的话题。UpdatePanel的方式可谓“全自动”：页面加载时将会把服务器端的Trigger信息输出至客户端，然后在客户端截获form的提交事件，并通过UniqueID或DOM结构等方式来判断这次提交是否该转化为AJAX方式。不过在一个ASP.NET MVC页面中几乎不会出现产生PostBack的元素，相反会有大量的普通链接，它们才是AJAX更新的主要截获目标。

  为此我提供了一些JavaScript代码，截获一个链接原本的目标地址并将其转化为一个AJAX请求。我在这里通过示例中的代码来展示这种使用方式（这个示例源于Brad Abrams提供的ASP.NET MVC示例，不过我舍弃了Northwind数据库与Entity Framework，取而代之的是XML数据以及自定义的简单Model。此外，我也将其移植到ASP.NET MVC框架的0416 Build中）：

   这段代码来自分类列表页。与AJAX改进之前的代码相比，唯一的区别就是额外指定了元素的onclick事件（加粗部分）。在onclick事件执行中，这个链接默认的跳转行为将被取消，取而代之的是一个AJAX请求，请求的目标便是ProductsController中名为List的Action。