3. 目前还只支持调用Web Services的服务，对于ASP.NET的内置的服务以及WCF的服务支持也没有看见，也不支持页面或控件内的方法调用
4. 功能上还不稳定，一些功能仅是在特定条件下的特性实现，还不能满足部署生产环境的要求。我认为，如果Atlas发布Go-Live License，那么可以考虑Atlas的放入到正式的项目或应用中。
我并不建议，你现在就将它应用在一个老的ASP.NET 项目中，或是老项目迁移到ASP.NET v2.0时优先考虑它；更多时候，如果你是创建一个新的ASP.NET应用，而又跨越了其学习曲线的情况下，可以考虑使用它。目前的情况下，对于Atlas，我建议，你应该保持足够的关注和实践学习，但是要抑制住将其应用到项目中的兴趣；因为Ajax，你现在可以开始关注和学习它，但是你不能因为要实现Ajax一个特性，而立即选择Atlas，那么是可能有风险的。
注： Atals 的Microsoft.Web.Script.Serialization 命名空间中有JavaScriptObjectDeserializer和JavaScriptObjectSerializer两个对象，第一，我不确定其是否也是JSON 序列化，而且我也不确定目前是否支持两路双向的序列化；第二，目前的版本，我还不能进行自定义或扩展，同时也很难对于其性能做任何的结论。
经典必看文章- Atlas 快速学习参考
http://atlas.asp.net/quickstart/default.aspx基于Ajax 架构的Web应用框架之前我提到过"似Ajax" 的架构，现在我要说的Ajax框架也就是指专门针对这种Ajax架构而提供的框架。目前，我还没有听说过特别好的这个领域的流行框架。但我知道我的身边，.NET领域，J2EE领域或PHP平台上都有这样的框架和应用，我认为，正是因为有很多这样应用，所以Ajax才会像某个模式一样，被撰有一个专门的名词。不过我感觉Ajax 渐渐变成了Ajax feature的代名词，变成了XMLHTTP的代名词，成了异步通讯，不刷新页面的技术表示法。直到我看过Ajax in Action这本书，我才把Ajax和系统的架构、设计模式，分布式对象的序列化和我之前的项目和经历联系在一切。
我修改了一些Jesse的图，来说明我认为的基于Ajax的架构是什么样的。
这也就是我上面说的“似Ajax”架构，首先它是一个Web应用；它的表现层用DHTML＋CSS ＋ HTC控件＋ Javascript ，服务器端用.NET或任何的服务器端技术，中间以XML方式序列化和反序列化进行传递数据。
简单的说，客户端需要将请求的数据封装成一个XML数据通过HTTP传递给服务器端，服务器端处理这个请求，并将结果也以XML的形式返回到客户端，客户端再处理这些请求，然后使用HTML+CSS进行展示。其实如果不是Web客户端(浏览器)的问题，这是最简单的架构，但关键问题在于上面我们说的Javascript端的对象封装成一个XML，以及到服务端解析XML变成服务器端对象，然后再将结果封装成XML，传回给客户端(Javascript)，客户端也解析XML数据，然后变成Javascript 中的对象的这个序列化和反序列化的问题。另外一个问题就是表现层的展现问题，怎么展现，用什么控件？
所以，一个Ajax架构的Web应用程序，必须解决下面的问题：
1. 双向两路的序列化问题
2. 表现层展现的问题
3. 传输时客户端和服务器端的数据安全问题
4. 性能问题
5. 国际化支持
最好玩的双向两路的序列化问题，最早接触的是JSON ，它的问题在于扩展性，数据类型的支持和性能，但是平台无关性比较好，什么浏览器都可以，因为它不需要用msxml2.DOMDocumen分析XML，本质上就是用字符串描述对象；之后多平台的应用的迁移经历中(比如CORBAR，J2EE的后台应用)，开始接触到
XML-RPC ，
ICE，
Hessian，Web Services等等。其中XML-RPC有Javascript 的
支持库，Web Services也有Javascript的
支持库，也就是你可以使用Javascript访问或者获得XML－RPC/Web Services的对象，但是如果你将其作为一个主要的通讯协议，那么就会遇到另外一些问题，比如性能、国际化的问题，又会困扰你，XML-RPC和Web Services的一个主要问题都是性能，因为他们传输的XML大小都太大了，但显然用这些实现一个Ajax的特性，那是完全没有问题了。
比如，Atlas目前不也是使用一个Javascript库调用Web Services吗？，所以，你也
可以这么做，同样你也可以用
XML-RPC.NET 很快就可以实现一个Service，然后使用Scotandrew的XML-RPC javascript 库就可以在Javascript中发一个XML-RPC 消息请求这个服务，然后异步的获得这个结果，然后展现它。所以从技术的实现上讲，Ajax的特性非常容易实现，但从架构上来看。你需要思考更多的因素。当然直到最后，我们才发现，在项目中，最完美的方案是你自己写一个双向两路的序列化引擎供你的Javascript客户端使用。
这就说到了第二个问题，界面表现的问题，这个问题也是一个大的问题。这个问题一直会永远存在，Ajax之前没有人会太注意这些，但今天不同了，我想未来还会有很大的一个飞跃， Yahoo! 不是最近也开源了
他的Yahoo! Web UI库，Atlas 也表示要提供更多的前端UI控件。无论如何，这个问题是，你的团队或组织是否有一套经过项目或客户检验的前端Javascript的库。无论是自己用Javascript写的也好，是自己写的一套HTC的控件库也好，总之这些是Ajax 架构中非常重要的一环。
本新闻共
6页,当前在第
4页
1 2 3 4 5 6
