Microsoft ASP.NET AJAX对于Atlas来说，不仅仅是一个名称上的改变，它从基础结构实现，到客户端与服务器端的应用，都发生了翻天覆地的变化。相对于Atlas来说，似乎Microsoft ASP.NET AJAX在各个方面都有了长足的进步。一些原有的诟病与硬伤得到了改善，可以说，相比于以前的Atlas，它成熟了。

CTP和RTM版本的Micrsoft ASP.NET AJAX改变基于以下三个目标：

用户反馈 -- 我们根据社区论坛里对于使用CTP版本创建Web应用程序的讨论和反馈做出了很多修改。
提高开发效率 -- 我们希望能在未来的Visual Studio中提供一些工具支持，例如script调试，客户端错误捕捉和报告等。另外，我们希望能够使用更清晰的模式改良编成模型，并且和.NET Framework的设计标准和原则相匹配。
优化性能 -- 我们希望能够为Debug和Release两种情形下减少加载时间和浏览器内工作的脚本大小，大量的脚本对象实例占用了大量的内存的问题被解决了。


下面的表格简要地表述了客户端JavaScript框架(Client FX)和ASP.NET服务器端框架（Server FX）对于各类开发人员所存在的目的。两者的设计都着重了今后扩展的可能。例如，Client FX的设计是为了满足我们对于性能的要求，并且能被服务器端控件（如AutoCompleteExtender）使用，另外它也提供了今后对于xml-script和binding的支持的可能。

Comment　　可以发现，Microsoft ASP.NET AJAX的目的，并不是对于Atlas现有功能的改变，它的设计目的似乎就是为了针对Atlas的不足——例如性能，这似乎是Atlas最大的缺陷了——而做了充分的努力。这种努力可能能够换来这个技术更长的生命力，但是也对熟悉之前产品的使用者来说是一种挑战——必须从头接受起。似乎Microsoft ASP.NET AJAX也准备了保留在之前Atlas中存在的功能（例如xml-script和binding），但是为什么不在完整它之后才发布呢？可能也是为了照顾使用者吧，能够早点开始接触新的东西总是好的。
另外，我在文章中保留了“Client FX”和“Server FX”，由于在这里它们具体指代了Microsoft ASP.NET AJAX的客户端框架和服务器端框架，尤其是其基础代码。如果简单地将其翻译为“客户端框架”和“服务器端框架”，个人认为会丧失其含义。
请注意：工具和设计器支持是针对下一版本的Visual Studio（Orcas）而言的。

Audience
Goals
Notes
ASP.NET页面服务器端开发人员
-      向已有的Web应用程序逐步地增加富客户端功能。
-      使用已被开发人员所熟悉的ASP.NET编程模型和工具进行开发。
-      减少，甚至消除JavaScript的知识的需要。
-      减少，甚至消除为特定浏览器编写代码的需要。
-      使用ASP.NET和.NET Framework的编程技能。
开发人员使用服务器端控件来开发Web应用程序，以此避免对于Javascript的直接操作，但是依旧满足了当前Web应用程序丰富的需求。
ASP.NET页面客户端开发人员
-      定义了Client FX，使开发客户端组件得到了简化。
-      提供了高效的开发体验，例如IntelliSense和调试支持。
-      减少，甚至消除针对特定浏览器开发脚本的需要。
希望进行页面纯客户端开发的开发人员，可以使用Client FX方便地进行开发工作。Client FX为创造对象，跨浏览器事件处理等工作提供了不小的便利。
ASP.NET组件开发人员
-      提供了一个框架，使ASP.NET组件开发人员能够方便地结合服务器端和客户端功能进行开发。
-      提供了编写组件的模式与概念，以分别支持Debug和Release的部署。
Client FX负责了浏览器的侦测和扩展。这部分功能配合增强的Client FX和Server FX，能够为组件开发人员构建富客户端控件提供了有用的部件。
这部分功能的一大目的是为第三方组件的开发社区提供了良好的基础。

Comment　　Microsoft ASP.NET AJAX愈发增强了对于开发人员的把握，这一点似乎已经成为了当且发展的重点。微软如是，其他公司也如是。


Overview of Major Changes

下面的表格概括了CTP（Atlas），RTM与Value-add发布版本之间的主要区别。所有的功能被分为了Client和Server两组，并意义描述其子功能，以及对开发人员影响。

Feature
Change Made & Purpose
Effect
Client FX
客户端类型系统
从使用closures改变成为使用proptotypes。
目的：
-      提高总体性能，减少对象实例所占内存。
-      为将来的会在Visual Studio “Orcas”中提供的IntelliSense而设计。
-      为Visual Studio的调试支持而设计。
-      提供了定义更为优秀的设计模式。
组件开发人员和页面开发人员能够使用一致的的模型在Client FX下开发自定义类型。
使用这些类型的开发人员只需一点细微的代码改变就能得到Visual Studio中的IntelliSense和更好的调试支持。
客户端事件模型
为绑定DOM事件和暴露组件的事件定义了事件模型。
目的：
-      支持一个标准的模型和可扩展性。
-      提供了和.NET Framework相似的模式。
组件开发人员和页面开发人员能够使用一个简单而且相似的模式来定义和绑定一个事件。
页面开发人员会发现一套更容易的新API来绑定事件。
浏览器兼容
通过对浏览器和浏览器能力的检测提供了完整的客户端兼容。
目的
-      使用了一个标准的模型。
-      简化了浏览器检测API。
组件开发人员和页面开发人员能够使用新的API方便地进行跨浏览器的开发
 
客户端JavaScript扩展
改变了API。
目的：
-      避免与其它AJAX类库的冲突，为了良好地与其它AJAX类库兼容。
组件开发人员和页面开发人员有了新的API，避免了与其它API有冲突。
客户端“类”与其它类型
将类的定义方式改成了基于prototype的形式，并封闭了各注册用API，取消了定义抽象类的方式。另外，提供了一种增强的异常处理方式。
目的：
-      更快的实例初始化。
-      提高总体性能，减少对象实例所占内存。
-      未来在Visual Studio “Orcas”中将提供IntelliSense功能。  
组件开发人员可以使用新的模型来定义类型。
页面开发人员可以使用新的简写方式来初始化一个类型，以此避免之前的复杂性。
Debug和Release脚本
定义了一个可选的模型来指定debug或release版本客户端脚本的使用，它独立于服务器端debug的设定。
页面开发人员可以使用ScriptManager控件内的release脚本，同时分别为服务器端和客户端指定debug或release模式。服务器管理员能够指定部署的配置设定，以保证在产品环境下使用release脚本。
目的：
-      第三方能够使用在Visual Studio中为debug模式的脚本提供的工具支持
-      使页面开发人员能够在产品环境下使用优化过的release脚本。
组件开发人员能够选择性地分别提供debug和release两个版本的脚本。
页面开发人员能够在经过网络优化过的脚本里得到IntelliSense和debug支持
客户端Component、Behavior和Control 类型
去除了binding和action，这些类型在Value-add发布中提供。RTM版本的发布设计了一个使用它们的方式。
原有类中的一些API被移至新的DomElement类中。
目的：
-      简化Client FX。
-      无需初始化一个控件实例，就可以使用这些API直接操纵HTML元素。
-      减少了脚本大小优化加载时间与性能。  
使用旧API的组件开发人员和页面开发人员必须修改他们的代码。
客户端网络管理
为了使用脚本访问Web Service方法创建了一个简单而且更加灵活的设计。
为提供默认的回调函数，和为回调函数传递方法名增加了支持。
使用静态的页面方法替换了原有的Page对象实例方法。
去除了脚本对于WCF（.svc）Web Service的支持。
去除了iframe的executor类从而避免了跨域名访问。
从CTP版本内移除了以下功能：
-      基于程序集的方法调用。
-      InitialData控件。
-      Web Service的批量调用。
目的： 
-      简化脚本访问Web Service的方式。
-      为计划中增强的WCF实现和与Visual Studio “Orcas”的集成做准备。
-      去除了跨域名访问的潜在安全漏洞。
-      从Client FX中去除了无用的功能，从而减少脚本体积，增加了性能。
-      减少了脚本大小，从而优化了加载时间，提高了性能。
页面开发人员能够使用一个更简单而且灵活的方式来处理网络相关的工作。
开发人员必须移除对于WCF（.svc）Web Services的引用，iframe executor和其他已经被Client FX排出在外的功能。
客户端访问