从Atlas到Microsoft ASP.NET AJAX（1） - Overview of Major Changes

　　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排出在外的功能。
客户端访问ASP.NET应用程序服务	为通过脚本使用Membership和Profile Service提供了一个简单而更加灵活的设计。它和客户端访问Web Service方法功能的增强保持了统一。 为指定默认回调函数提供了支持。 额外Value-add的发布，实现了一个组件用于访问Profile service。 目的：简化脚本访问ASP.NET应用程序服务的方式。	页面开发人员可以更加方便地使用ASP.NET应用程序服务。
Value-add发布：高级的客户端组件，XML-Script支持，客户端数据以及类型描述符（type descriptor）	原来Sys.*下的功能被移动至新的命名空间Sys.Preview.*下。 为Client FX增加了一种简单的类型描述符，它能在Value-add发布中使用。 Value-add继续支持原有的XML-Script并提供以下的增强： -     Binding可以无限地在Component中嵌套。 -     提供了一种更好的“命名空间”与“前缀”的关联方式。 目的：为RTM release重构Client FX。	页面开发人员必须修改其XML-Script的代码。 转移至Value-add包中的部分可能需要进行修改。 组件开发人员使用RTM版本开发的组件也能够在Value-add中使用。

Comment

　　客户端的脚本进行了一番非常大的修改。如果查看Client Script的话，会发现只有三个文件了。它们提供了Microsoft ASP.NET AJAX的核心，把大量的额外功能转移到了另一个Value-add包内。其中，MicrosoftAjax.js“勉强”对应当时的Atlas.js（当然功能少了许多），只有一些简单的控件了。这些控件会支持了Server FX的功能，因此也是彻底无法剥离了。看样子，Value-add包的应该会超出原有Atlas的功能，按照现在的样子应该也会分成几个js吧。我猜想另外的一些比如Map的集成，应该可以去掉了吧，意义不大，而且似乎原本也就是个Virtual Earth API的简单封装，而这些信息在Windows Live Dev上也有。
另外，MicrosoftAjaxRuntime.js还是提供了一些Javascript中简单的扩展，和面向对象的能力。不过我觉得最值得一提的应该是第三个文件：MicrosoftAjaxWebForms.js。简单的扫了一下代码，它似乎提供了客户端的一个Page模型。在官方网站上看到类似内容的介绍，我想应该就是这个文件提供的功能吧。在客户端创建了一个异步的Page生命周期模型，应该是一个创举，不过似乎也有着强烈的ASP.NET气息。
总的来说，客户端代码体积减少了，但是功能被裁减得更多，因为加强了对客户端基础的建设。看了文档的描述，似乎对这个Microsoft ASP.NET AJAX的功能有了不错的印象。不过，还需要更深入的研究……

Feature	Change Made & Purpose	Effect
Server FX
ScriptManager控件	对ScriptManager控件进行了修改，使之能够支持UpdatePanel控件的新功能，例如能在UpdatePanel控件中注册脚本以及样式表。另外，Error Template功能已经被移除。 提供了新的操作方式来引用静态的或Web Resource输出的脚本信息，并引入了新的事件来提供自定义脚本位置功能。 增强的ScriptManager提供了新的debug和release脚本的控制方式，因此现在无需依赖config中debug设置。 增强了某些控件（例如各种Validator，这样就能在UpdatePanel中使用它们了）。 控件必须把自己的资源（脚本，样式表）通过ScriptManager控件的等价方法（取代ASP.NET中的ClientScript中的方法）来注册。 目的：根据用户反馈与建议，给予了页面开发人员在使用UpdatePanel时更强，更灵活的脚本控制能力。	页面开发人员在脚本管理方面得到了更好的控制能力。 组件开发人员必须通过ScriptManager注册组件的资源和脚本。
ExtenderControl控件	Extender模型被简化，提供了一个控件对应多个Extender的支持。 改变了定义和注册控件脚本的模型，使脚本在运行时生效以减少对于页面生命周期知识的了解。新的模型支持简化的JSON形式的对象构造方法，和一些以后出现的模型。 为Orcas增加设计期支持，使Extender能定义自己的目标对象类型。	组件开发人员能够使用简化的模型来开发Extender。 页面开发人员能使用简化并增强的Extender标记语法。
UpdatePanel控件	对其进行了修改，以保证它在各种已知的Partial-Update问题中运行正常。这意味着： -     控件必须把自己的资源（脚本，样式表）通过ScriptManager控件来注册。 -     UpdatePanel不再纪录整个页面内容的改变，它只会关心自己Content Template中的内容。 在客户端的PageRequestManager控件里增加了几个事件，可以支持更多种不同的异步回调的场景，例如生成动画和Progress效果。 现在，UpdatePanel控件除了能够使用Tag的方式之外，还能被动态地添加到页面中。 触发器模型被增强了，属性触发器被移除，增加了PostBack触发器，以此能够在UpdatePanel控件中刷新整个页面（即传统的同步刷新）。 目的：根据用户的反馈与建议，提供了组件开发人员更灵活的选择：是局部刷新，还是完整的PostBack。	组件开发人员必须使用这种注册资源模型。 页面开发人员能够使用新的方式使用UpdatePanel控件。
Server控件的Tag Prefix改变	将<atlas: ... />变成了<asp: ... />。 目的：将ASP.NET 2.0 AJAX Extensions和ASP.NET的服务器端控件用同样的标记语言，统一了使用方式。	开发人员必须修改把所有的atlas前缀改成asp。
Value-add发布： 服务器端组件	Microsoft.Web.*下的功能被转移到了命名空间Microsoft.Web.Preview.*下。 目的：为RTM release重构Server FX。	转移至Value-add包中的部分可能需要进行修改。 组件开发人员使用RTM版本开发的组件也能够在Value-add中使用。

Comment

　　对于服务器端的改变，我最感兴趣的可能就是ExtenderControl了。Atlas中的ExtenderControlBase基类的功能的确过于疲软，以至于需要在Atlas Control Toolkit中对Extender的基类进行扩展。ASP.NET 2.0 AJAX Extentions中的EnternderControl我还没有研究过，莫非它就是将Atlas Control Toolkit的功能给集中进来了吗？如果不是的话，那么Atlas Control Toolkit中大大小小二十多个控件莫非都要相应地进行改变？另外提到的Orcas设计期支持是指什么？是指范型吗？Extender是Atlas中最典型的一个服务器端控件，它的各种疑问只能等以后再慢慢挖掘答案了……
关于UpdatePanel，它的一些功能增强使得我在园子里看到过的一些问题得以解决，例如在UpdatePanel的Update时增加Extender，这是就会产生脚本没有引入的错误。这个问题现在似乎只要通过ScriptManager注册脚本就可以了。这样的话看来问题是依靠开发人员获得更大的操作性而解决的，不过这个应该不是问题。另外，动态添加UpdatePanel也是个长足的进步。

Feature Matrix

ASP.NET AJAX的RTM Release准备被拆分成了两部分提供下载。下面的列表是原有的CTP功能的集合，以此来表示目前那些Feature在RTM Release分别存在于哪个包中：ASP.NET AJAX 1.0，还是社区支持的Value-Add CTP release。

Comment

　　依旧是提到了社区支持，外界一直声称微软如何抵制开源，其实微软也在积极地加入社区（即使为了其商业目的）。可能微软以后以后也会为了Microsoft ASP.NET AJAX的扩展增加一个像Windows Live Gallery一样的地方吧，毕竟提供了如此高的扩展能力，不加以好好利用就太浪费了。
以下就是文档上面完整的列表，内容没有值得再解释的，不过我将其最右边的栏目名“ASP.NET AJAX CTP”改成了“Value-Add CTP”，否则即使它并没有错，这种写法也太容易产生歧义了。

Feature	ASP.NET AJAX 1.0	Value-Add CTP
Server features
Asynchronous client-to-server networking	ü
Authentication as a Web service	ü
AutoCompleteExtender class		ü
ControlExtender class	ü
Cross-browser Web Parts drag-and-drop		ü
DragOverlayExtender control		ü
PopupExtender class		ü
Profile as a Web service	ü
ScriptManager and ScriptManagerProxy controls	ü
Static page methods as Web services	ü
Timer control	ü
UpdatePanel control	ü
UpdateProgress control	ü
Client Features
Actions components		ü
Authentication for JavaScript	ü
AutoCompleteBehavior class		ü
BatchResponse class		ü
Behavior class	ü
Binding component		ü
Button control		ü
Calling .asmx Web services from JavaScript	ü
Checkbox control		ü
Click behavior		ü
Component class	ü
Control class	ü
Counter class		ü
Cross-browser Web Parts		ü
Data control		ü
Debug class	ü
DragDropList control		ü
DragDropManager component		ü
DraggableListItem control		ü
FadeAnimation component		ü
Floating behavior		ü
Hover behavior		ü
Hyperlink control		ü
Image control		ü
Input control		ü
JavaScript Array type extensions	ü
JavaScript Boolean type extensions	ü
JavaScript Error type extensions	ü
JavaScript Number type extensions	ü
JavaScript Object type extensions	ü
JavaScript String type extensions	ü
JSON serialization	ü
Label control		ü
Layout behavior		ü
Opacity behavior		ü
Popup behavior		ü
Profile for JavaScript	ü
Selector control		ü
ServiceMethodRequest class		ü
Sys.Data and Sys.UI.Data namespaces		ü
Textbox control		ü
Timer control		ü
Trace class	ü
Validator controls		ü
xml-script support		ü