“深入Atlas系列”文章导读

　　“深入Atlas系列”的路还很长，还有许许多多的东西可以分析与挖掘。这个“文章导读”既是对这个系列文章的一种整理，也是对我坚持完成这一系列的一个自我鼓励与鞭策。

从现在开始，我决定从现在开始将“深入Atlas系列”的文章分为“分析”与“示例”两部分。“分析”部分文章可能会相对比较“枯燥”，因为它几乎完全就是从实现角度对Atlas的原理进行剖析，附带一些说明性的简单示例。但是这才是我精力花费最大的地方。这部分文章都是“示例”部分的实现依据。“示例”部分文章使用了“分析”部分所得到的结论，然后设计出来的Atlas使用示例。它们用一种比较直观的方式对一些复杂或高级的问题提供解决方案。

既然是“深入Atlas系列”，我会尽可能保持这个系列内容的“深入”性，讨论的内容也尽可能地避免流于表面或者已有的文档和示例，因此这对我的要求也会相当的高。请朋友们有也不要吝啬您的意见、建议和疑问。你们的支持是对我最大的鼓励。如果您希望深入了解Atlas的哪个部分，也请尽管告诉我。


“深入Atlas系列”文章导读 - “分析”部分

客户端代码编写规则分析与编写指南

　　在RTM版本中，我们可以发现ASP.NET AJAX的客户端脚本引入了许多规则：有方法注释规则，有参数验证规则，而且对于Debug和Release模式下的脚本代码，甚至添加在程序集里的方式，也有相当严禁的规则。如果我们想要编写真正规范和严谨的代码或组件，了解这些规则是非常必要的。

客户端网络访问基础结构（上） - WebRequest的工作流程与生命周期

　　ASP.NET AJAX的许多功能会要求异步地访问服务器端，例如访问Web Services，Authentication/Profile Services（事实上和访问Web Services是相同的机制）和Partial Rendering。在ASP.NET AJAX中，所有的这些访问都是通过一个网络访问的基础结构来完成的，无一例外。

客户端网络访问基础结构（下） - WebRequestExecutor和XMLHttpExecutor

　　正如前一篇文章所说的那样，WebRequestExecutor是客户端网络访问的基础结构的唯一扩展点，而XMLHttpExecutor是其默认实现。在ASP.NET AJAX中，开发人员能够将自定义的WebRequestExecutor子类设为默认的Executor，也可以为某一个WebRequest指定一个特定的Executor。虽然一般来说XMLHttpExecutor已经足够大多数应用，但是既然ASP.NET AJAX提供了这个功能，我们也根据默认的类进行一下这方面的学习。

Web Sevices Access in Atlas（7） - RTM中的客户端支持

　　在RTM版本中，客户端访问Web Services的基础类库发生了一些改变，并直接影响到了它们的使用方式。对于自己写ASP.NET AJAX组件（例如ExtenderControl）的朋友们来说，了解这部分改变是非常重要的。

Web Sevices Access in Atlas（8） - RTM中可叹的Web Service Proxy

　　使用Web Service Proxy应该是使用ASP.NET AJAX访问Web Service最常用的方法了。服务器端会根据ScriptManager中添加的Service引用而对于Web Service类进行分析，并生成相应的客户端脚本。这样开发人员就能在客户端方便而且直观地访问Web Services方法了。这是ASP.NET中很重要的功能。从官方文档上看来，CTP和RTM似乎在脚本使用这方面没有很大的改变，只要在服务器端将一些CustomAttribute改变一下就可以了。的确没有错，在使用方式上只有这点细微改变，但是事实上，从生成脚本本身来说，CTP和RTM的做法大相径庭。

探究Application Services（1） - Profile Service分析与使用

　　ASP.NET AJAX提供了Profile Service，允许开发人员异步地从服务器端访问Profile信息。从RTM开始，客户端的Profile Service还提供了对于Profile Group的支持，因此可以说已经相当成熟了。那么对于Profile Service的细节，是否大家都了解了呢？从ScriptManager的使用上来看，ProfileService是能够扩展的，那么应该如何扩展呢？细心的朋友们应该也发现了，在web.config中也增加了对于Profile Service的配置，那么这些配置应该如何使用呢？

探究Application Services（2） - 自定义服务器端Profile Service支持

　　在上一篇文章中，我们讨论了使用ASP.NET AJAX默认的Profile Service。一般来说，它已经能够迎合大多数应用的需要了。不过除此之外，ASP.NET AJAX还提供了让我们自定义Profile Service的机制。

探究Application Services（3） - 自定义客户端Profile Service支持

　　如果不能在客户端进行自定义的话，Profile Service的自定义能力还是远远不够的。虽然Profile Service没有提供一种“官方”的客户端自定义支持，不过事实上“自定义”能力“天然”地存在与客户端里。为什么？因为整个客户端是由JavaScript实现的，这种灵活的语言使得我们能够在一定程度上自由地修改客户端的行为。

探究序列化与反序列化能力（上） - 客户端支持，JavaScriptTypeResolver与JavaScriptConverter

　　在ASP.NET AJAX中使用了JSON作为客户端与服务器端传递对象信息的方式。因此，在ASP.NET AJAX的客户端与服务器端均提供了序列化与反序列化的能力。了解这些内容的使用方法，可以说是使用与扩展ASP.NET AJAX所必须的能力。在这两篇文章里，我们就来看一下ASP.NET AJAX中的序列化与反序列化的能力。

探究序列化与反序列化能力（下） - JavaScriptSerializer

　　在ASP.NET AJAX中，客户端的序列化与反序列能力由Sys.Serialization.JavaScriptSerializer类的serialize和deserialize两个静态方法提供。在服务器端，所有的序列化与反序列化能力，包括类型之间的转换，对于开发人员来说都是由JavaScriptSerializer类的几个方法实现的。从前一片文章里我们已经知道了两个辅助的类：JavaScriptTypeResolver和JavaScriptConverter，他们的作用分别是“映射类与类标识”，以及“提供特定类的序列化与反序列化能力”。在某些情况下，我们还是需要使用JavaScriptSerializer类的方法来操作一个类型，例如使用JavaScriptConverter来自定义特定类的序列化或者反序列化，就需要使用JavaScriptSerializer类的方法，因此我们这次就详细看一下这个类的能力。

浅析ASP.NET Beta 2中令人疑惑的脚本引入方式

　　似乎已经有不少朋友在作了ASP.NET AJAX Beta 1到Beta 2的转移之后遇到了这样的问题：如果使用了ScriptManager引入了自定义的JavaScript脚本文件后会发生JavaScript错误。本文简单讨论了引发这个问题的原因，解决方案以及注意事项。

Web Sevices Access in Atlas（1） - 客户端支持（部分内容已过期）

　　Atlas提供了强大而灵活的服务器端Web Services访问能力。这对于客户端AJAX开发提供了绝好的条件，这几乎也是任何AJAX框架必备的功能。因为只要有了它，就能轻松地以AJAX方式与服务器端进行交互，而其他多样的页面操作自然可以由开发人员尽情开发。对于部分喜欢自己动手的开发人员来说，这甚至是他们仅仅需要的支持。
本文分析了Atlas访问Web Services方法所使用的部分客户端代码，这部分代码是Atlas客户端访问Web Services方法所使用的最基本的代码。

Web Sevices Access in Atlas（2） - 服务器端支持（上）（部分内容已过期）

　　在上一片文章里，我们分析讨论了使用Atlas在进行AJAX访问Web Services所用的客户端代码。但是如果要实现这一功能，很显然还离不开服务器端的支持。在这篇文章里，我们就来讨论这一点。
本文分析了Atlas对于客户端访问Web Services方法所作的扩展，以及Atlas获取和识别所用Web Services信息和Atlas处理该Request做准备的实现。

Web Sevices Access in Atlas（3） - 服务器端支持（下）（部分内容已过期）

　　在上一篇文章里，我们分析了一部分服务器端的代码。在这篇文章里，我将完成服务器端代码分析，并提供“在Web Services方法中使用复杂的数据类型”和“使用Web Services将对象序列化成XML并使用客户端XSLTView空间输出信息”两个简单的范例让大家参考。
本文分析了Atlas访问Web Services方法时，对于该Request的处理以及将方法执行结果返回客户端的实现。

Web Sevices Access in Atlas（4） - 对于复杂数据类型的支持（上）（部分内容已过期）

　　Atlas访问Web Serivces方法对于复杂数据类型的支持并不如前几片文章所描述的那么简单。从这篇文章开始，我将从实现角度详细分析Atlas访问Web Services方法是如何支持复杂数据类型的，并最终对于一些常见的情况给出解决方案。
本文分析了Atlas对于数据传输和类型或形式转换的整个过程，以及客户端对于一个对象的序列话方式以及其扩展能力。

Web Sevices Access in Atlas（5） - 对于复杂数据类型的支持（中）（部分内容已过期）

　　这篇文章继续讨论了Atlas访问Web Services方法时对于复杂类型的支持，并从实现角度分析了可以说是此中最重要的那部分代码。这部分内容是扩展Atlas对于复杂类型支持的依据，由此可以得出Atlas的一些强大之处。
本文分析了Atlas服务器端在获得客户端数据之后，将其反序列化成合适类型对象以供Web Services方法调用的实现以及扩展能力。

Web Sevices Access in Atlas（6） - 对于复杂数据类型的支持（下）（部分内容已过期）

　　这篇文章将Atlas访问Web Services方法对于复杂类型的支持讨论完毕，在之后的文章中将通过示例着重讲解一些有用的功能和在文章中提到的扩展。
本文分析了Web Services方法寻找自身所支持的复杂类型的方式，以及将对象序列化输出的实现和注意点。

“深入Atlas系列”文章导读 - “示例”部分

客户端网络访问基础结构示例（1） - 编写并使用自定义的WebRequestExecutor

　　WebRequestExecutor是ASP.NET AJAX网络访问基础结构的唯一修改点。理论上，我们可以使用自定义的WebRequestExecutor来取代默认的XMLHttpExecutor。我们要做的，其实只是开发一个继承于Sys.Net.WebRequestExecutor类。不过事实上，在实际使用中，Sys.Net.XMLHttpExecutor已经足够用了，真的要自定义，也只需继承这个类即可。就像接下去的例子一样。

Web Sevices Access in Atlas示例（1） - 特别的访问方式（部分内容已过期）

　　本文从实现角度讨论了使用Sys.Net.ServiceMethod.invoke以及Declarative Syntax调用Web Services的方法。并通过示例指出了Atlas现有的组件的不足并提供了改进办法、源文件以及示例。本篇文章提供了三个示例：
1、使用Sys.Net.ServiceMethod.invoke静态方法访问Web Services
2、使用Declarative Syntax访问Web Services方法
3、使用改进的Declarative Syntax访问Web Services方法

Web Sevices Access in Atlas示例（2） - 自定义JavaScriptConverter处理循环引用对象（部分内容已过期）

　　在以前的文章中我曾经举了一个简单例子，如果一个对象存在着循环引用，那么无论在客户端还是服务器端都会出现异常状况。这篇文章将通过示例来解释如何使用自定义JavaScriptConverter来解决这个问题。

Web Sevices Access in Atlas示例（3） - 在Web Services方法中使用多态（部分内容已过期）

　　在Web Services方法中，我们往往使用的都是一个具体类型的参数。这个参数一般就是一个数据对象，所有的功能基本上只是为了存放数据。虽然这对于应用来说一般已经足够，我们大量使用了这样的Web Services，不也过得好好的吗？但是，在这一点上实在太不够“面向对象”了。本文提供了示例演示如何在客户端选择传递给Web Service参数的具体类型，以达到一定程度上多态的效果。

Web Sevices Access in Atlas示例（4） - 使用HTTP GET调用Web Services方法（部分内容已过期）

　　在之前的例子里，由于Atlas客户端在调用Web Services方法时总是使用了Sys.Net.ServiceMethod类，因此始终使用了HTTP POST方法与服务器端进行交互。POST方法有其好处，不过GET方法也自有其价值。本文通过示例解释了如何使一个Web Services方法能够通过HTTP GET调用，并且如何调用它。

Web Sevices Access in Atlas示例（5） - 自定义TypeConverter把基础类型转换为复杂类型（部分内容已过期）

　　在上一个示例中，我们了解到如何通过HTTP GET来访问Web Services方法。很显然，使用HTTP GET依靠Query String传递参数，于是在客户端拿到的总是基本数据类型String。幸好，在Atlas中，对于基础类型的参数，如果遇到了一个字符串，则会设法将其转换成一个合适的类型。因此在使用HTTP GET方法传递参数时，在Web Services方法里能够使用个中各样的基础类型。但是，这显然远远不够，Atlas也不会将这个问题置之不理。在Atlas中，自提供了一套自定义机制可以将基础类型转换为复杂类型。
本文通过示例演示了如何通过自定义TypeConverter来提供这种转换。

深入Atlas系列：Web Sevices Access in Atlas示例（6） - 在客户端隐藏服务器端类型信息

　　如果要在客户端指定服务器端Web Service方法所接收的参数类型，就必须在客户端通过“__type”来指定，但是这就暴露了服务器端的具体类型了，这可不太好。现在我们就来看一下应该如何解决这个问题。

Web Sevices Access in Atlas示例（7） - 编写JavaScriptConverter处理含有循环引用的类型

　　有时候在Web Service中会需要使用到比较复杂的类型，它们的特征往往都是含用循环引用，这样的对象如果交给ASP.NET AJAX中默认的序列化方式来处理则会抛出异常，大家经常遇到的“DataTable”问题正是由此引起的。关于这一点，ASP.NET AJAX自然提供了解决方法，在这里“官方”的解决方案就是JavaScriptConverter，它可以让开发人员自定义特定类型的序列化能力。

深入Atlas系列：综合示例（1） - 调用服务器端方法时直接获得客户端具体类型

　　在使用ASP.NET AJAX时，大家对于返回服务器端的复杂类型的情况经常会遇到问题。Dflying兄写了一篇文章来说明在如何在客户端得到Sys.Preview.Data.DataTable对象的文章，但是这种方法需要在客户端进行Sys.Preview.Data.DataTable的构造，那么我们该如何直接获得这个对象呢？再进一步，我们该如何直接获得客户端某种特定格式的对象呢？本篇文章给出了一个解决方案，事实上，这个扩展的能力还不止如此……