怎样的AJAX才算是理想？

要说什么是理想的ASP.NET AJAX，就要先说说什么是理想的AJAX。事实上AJAX最不理想的地方在于search engine friendly以及bookmarkable，这两个问题有一定的相似性，要解决并不难，只是每一个系统中实现起来都不一样，因此难以提出一个统一的patterns来解决。

首先说说search engine friendly这一点吧，实际上使用了AJAX的站点有很多信息是搜索引擎无法索引到的，因为页面上部分的信息是在用户进行操作后才显示的，显示的这些信息有可能是固定的也有可能是经过XHR(XMLHttpRequest)查询服务器后动态显示的。如果是固定信息，那么在生成页面时就要考虑这些信息是否也应该输出为静态HTML。那么什么情况下该输出为静态HTML而什么情况下不该输出为静态HTML呢？我觉得应该看隐藏的内容是否就是页面语义的一部分。例如页面用于显示一张集体照，当鼠标指向照片上不同人物时将显示他们的姓名和有关的介绍，那么这些信息就应该输出为静态HTML了，因为它们是页面信息的重要组成部分，并且这些信息应该被搜索引擎索引到。

当然，事情并非任何时候都那么简单，有时候我们并不能简单判断某些信息是否应该属于一个页面，或者说一个URL。例如你使用一个页面来展示你的gallery，但并非一下子显示所有的照片，开头显示随机的10张图片，然后允许用户输入/选择tag来显示对应的照片，如果当前显示的照片超过10张还会自动分页。这时候怎么办呢？整个gallery输出的一个静态页包括所有的照片以及描述？这看起来不太可行。假如你的gallery有100个tag和1000张照片，同时这一个页面成功被搜索引擎索引了，用户通过搜索引擎来到gallery页，他怎么找到搜索引擎上匹配的图片以及对应的描述？他根本不可能知道他要找的信息藏在哪里了，100个tag中可能只有几个能让他想找的信息显示出来。

这时候比较好的做法就是将tag分离出来变成独立的页面，或者说是URL。gallery首页上的tag对于用户来说是交互式按钮，在不刷新的情况下直接筛选对应的照片；但对于搜索引擎来说那是链接，链接到代表该筛选状态的页面，并且在该页面上才索引到照片和描述。这样当用户点击特定的搜索结果是，进入的是已经筛选了的gallery结果页，也就必然能看到他搜索命中的信息。同时这也增加了bookmarkable的可能性，因为一个URL已经不仅仅代表一个页面，而代表一个页面的特定状态，因此状态变得bookmarkable。然而这时候普通的筛选结果还不是bookmarkable的，因为在进行根据tag筛选后URL是不会被改变的，因此我们必须通过JavaScript改变URL才能让页面变得bookmarkable。

与理想的距离有多远？

我们面临最大的问题就是URL与状态的对应，以及有关的存取。我们希望每一个indexable & bookmarkable的状态都对应一个URL，而且最好是meaningful的URL。好吧，我们先舍弃meaningful这一点来探讨状态问题，实际上我们已经有一些方法来保存状态。例如ASP.NET提供的ViewState就是一个很好的例子。很多ASP.NET的新手可能会觉得要理解如何正确使用ViewState并不容易，其实它就是用于保存view的state的。整台计算机其实也就是一个state machine，不过我们当前所关注的是与view有关的state，所以称之为ViewState。ASP.NET开头的策略是在服务器端处理一切，所以发明了ViewState并尝试让状态在客户端仅作持久不作修改。然而我们需要的正好是相反的，我们需要一个在客户端能修改的状态，并且以URL作为持久的方式。

首先，我们不可能好像ASP.NET保存ViewState那样保存数据到URL当中。即使我们舍弃了meaningful，ViewState的容量还是会超过URL的长度限制，因此希望好像ASP.NET那样每一个控件各自汇报自己的ViewState然后页面负责统一持久到URL是难以实现的。（当然，在ASP.NET AJAX中尝试一下这样的实现也未尝不可，虽然其提供的控件少之又少。）

既然我们不能够好像ASP.NET保存ViewState那样“放肆”地利用URL进行持久，那么我们就必须针对特定的应用来考虑持久的方式，这正是无法开发一个通用框架实现此功能的原因。例如上面所说的gallery，我们要人为的考虑使用tag作为区分view的一个状态参数，接着我们可能还要考虑当用户选中多个view之后会发生什么事，是不是简单的在URL里面叠加多个tag呢？例如gallery.html#fun+event的样子？那么它和gallery.html#event+fun是等效的，而两个URL会不会导致PageRank的分散呢？之后又如何加上分页参数呢？这一切问题不是没有答案，而是它们的答案都太具针对性了，因此不具有通用性，难以做成一个可复用的框架实现。

因此我们在这里能做到的最多就如ASP.NET Futures或者别的框架提供的history功能那样，提供一个有限容量的string空间给你，你要自己决定如何把状态转换为string然后提交给它保存，之后它保你实现跨浏览器的Permanent URL和history支持。

到此为止，我们站在client centric的角度讨论了AJAX现在面临的一些重要障碍，以及潜在的解决方案。下一part我们将从server centric的角度来继续研究这个问题，并探讨ASP.NET是否能在AJAX方面做得更好，又或者是别的Microsoft技术。继续关注本文章系列，欢迎订阅Cat in Chinese(feed)或Cat in dotNET(feed)。