ajax 在目前 web 领域已广泛应用，其真正核心只不过是一个封装好了的 js 库。最五花八门的莫过于 asp.net 的控件，我个人认为 ajax 只是一个轻量级的东西，根本没有必要将它写成服务器组件，如 ajax.net、AjaxControlToolkit 等。所以我一直视这些组件为垃圾。。。
以下说明我为什么不认同 ajax 的相关组件：
1、将 ajax 封装得太死，出现问题难于调试；
2、组件过于臃肿，太多没有用的功能；
3、依赖性太强，少一样不可，如 webform；
传统的 ajax 应用到项目中，会出现由于项目的 ajax 应用太多，服务端的 ajax 响应函数难于管理，我们到底要把这些响应函数部署在什么位置？
假如
index.aspx 里有三个 ajax 响应函数，我们可以把这三个响应函数放在 index.aspx 中，并于 Page_Load 事件中根据参数不同来调用这些函数。
index.aspx 里还使用了 abc.ascx，这个控件里面也用到了 ajax，那么 abc.ascx 里的响应函数又应该放在哪里？index.aspx 中吗？如果 index2.aspx 中也用到了 abc.ascx，难道还要复制 index.aspx 的处理函数到 index2.aspx，这样肯定不行；
我们可以新建一个 ajax.aspx 来处理所有的 ajax 响应，php/asp 都可以这样做。这样管理还是不理想，
最理想的管理方法应该是页面、控件与响应函数集成。ICallBackEventHandler 可以做到，但是它依赖 webform，假如你的页面中没有一个 ，则会失效。
问题回归到如体使用轻量级 ajax，并实现页面/控件与 ajax 响应函数集成。
Reflector 查看 System.Web.UI.Page 里面处理 ICallBackEventHandler 模块后，我们可以这样做：
1、所有页面继承 BasePage；
2、BasePage 继承 System.Web.UI.Page，重写 BasePage.OnLoad；
3、实现 AjaxHandler
4、添加 Ajax 类，实现 Ajax.Register 静态方法
代码如下：
public class BasePage : Page {
protected override void OnLoad(EventArgs e) {
AjaxHandler();
base.OnLoad(e);
}
ajax handler#region ajax handler
//我喜欢用 json 格式数据来返回给客户端处理
protected void AjaxHandler() {
在web config中 作如下配置：
<connectionStrings>
<add name="ydycon" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=|DataDirectory|ydy.mdb" providerName="System.Data.OleDb"/>
</connectionStrings>
在.net文件中应用链接 ......
ASP.NET 应用程序必须位于 IIS 虚拟目录（也称为应用程序根目录）中。ASP.NET 应用程序可包含已编译的程序集（通常是包含业务逻辑的 DLL 文件）、用于存储预编译代码的已知目录（目录名总是 \Bin）、存储在基于文本的、易读的 Web.config 文件中的配置设置、页、服务器控件，以及 XML Web 服务。
服务器中任何不与其他应用 ......
