Atlas 带来了另外一个思考问题，就是服务器端控件可能可以通过某种方式和Javascript的控件很好的集成在一起，以前我们用HTC解决了重用、性能、Behaviors、甚至模板功能。但是新的特性还是有比如数据的绑定、缓存和校验、甚至是数据编码和压缩、加密和解密，Javascript UI前端还是有许多可以做的，而且如何无缝的集成两者，这个有非常大的意义。
接着安全、性能、国际化等等，架构中的问题需要你依次考虑和解决，如果这么看Ajax，我认为，目前的Ajax框架还有很长很长一段路要走，同样真正完美支持Ajax架构的还需要继续努力。这些也是我在
这篇专栏文章中的观点。
把这些合在一起，那么Ajax架构的开发包或框架，就应该是包含了上述几个问题(两路双向的序列化、Javascript UI 表现库、安全、国际化和性能等等)解决方案的一个平台实现。
同样也许你会说，不就是Ajax吗? 我干嘛要搞这么复杂，一定要搞到架构这个层面。
我认为，
第一，从架构的层面看Ajax，然后再应用相关的技术，比你直接使用某个Ajax框架然后再理解Ajax，你会从这个过程中收获更多。
第二，对于一个开发团队/组织来说，真正Ajax架构的产品，可以带来效益和具体的生产力。比如，我身边就有拥有这样的优势的团队，他们拥有一套统一的由Javascript+HTML+CSS+HTC的前端表现层，而后台的业务系统有两个平台，一个.NET平台和J2EE平台；同样我身边的也有这样的团队，他们拥有一套统一的由Javascript+DHTML+CSS+HTC＋VML+ASP.NET的前端表现层，但他们的后台业务层分别来自.NET平台、J2EE平台和Unix平台，我不能说Ajax架构的应用似乎就是统一Web 表现层。因为从今天看到他们的明天，也许会是, 一个ASP.NET V2+Atlas 的统一表现层，一个统一CAB+Smart Client 的统一表现层，也可以是一个WPF 3D的统一表现层，也可以是一个Xgl 桌面的统一层。。。。
第三，从这架构的层面上，你也能够非常容易理解SOA或ESB概念，和SOA相比，Ajax架构的区别在于，Ajax有足够的松散耦合，但它依然以应用的数据为中心，更多的是一个面向Messages的架构，而且对于流行的WS-*协议的支持非常有限。
但是假如，今天你或你的团队已经有了一个Ajax 架构的应用，那么你是不是应该要小心选择现有的Ajax框架，因为这些Ajax的特性，相对于目前的架构来说，是多么小，但又可能会产生很大危害的一个因素。也许这样的团队并不多，也许也很多，但是只有我们从更高更深的层次来思考，那么我们就能做出正确的选择，并且从新的Ajax技术和研究中获得好处。
结论当我们回到文章的起点，我希望这样能够说明的我观点，即Ajax-NET的框架或实现分为两类，一类是基于Ajax应用程序架构的，一类是基于Ajax特性的，目前几乎大部分的Ajax-NET的框架或实现都是基于Ajax特性，以Add-in 方式提供的代码或框架。
Ajax-NET的实现/框架选取上的建议：
- ASP.NET控件形式已经成为连接服务器和客户端Ajax通信的主要形式和选择。
- 客户端调用服务器端页面中的方法是Ajax的重要手段，使得客户端可以更加灵活的获得服务器端的数据。
- MagicAjax.NET，Anthem.NET用了"Hook ASP.NET"和Add－In的技术手段，使用上受到的影响比较多，这两个框架中，最简单的应用，第一选择MagicAjax.NET，但总是优先使用Anthem.NET
- 如果是自己写的服务器端控件，那么应该先掌握Anthem.NET的技术，然后使自己的控件拥有Ajax的特性
- MagicAjax.NET, Anthem.NET和wwHoverPanel 对于国际化的支持都有待加强
- 在Atlas没有正式发布之前，在ASP.NET的应用中优先在自己的项目中使用类似wwHoverPanel的技术，即尽可能的使用客户端回调功能，在特别需要的地方使用其方法调用的功能，充分发挥Ajax的特性，而不要因为Ajax而特意选择某个Ajax的框架
- Atlas的强项在于服务器端和客户端控件特性的集成、客户端的数据绑定、校验、内置的多个客户端Ajax 特性UI或组件，与ASP.NET的Profile, Membership ,Role 服务的集成，与Web Services和WCF 服务的集成，以及良好的国际化/开发工具支持的。因为它是一个完整的解决方案，所以最大的弱点是不能很容易地被老的Ajax架构的应用使用。另外该产品目前还在不断开发中，距离部署到生产环境中的要求还有差距。
- 轻量级的双向序列化可以考虑JSON格式，安全问题可以在传递的对象中增加字段，然后在服务器端进行校验。
- 对于原来已经有一套序列化框架的组织来说，其主要的目标是尽快将这个框架迁移/升级到ASP.NET V2，而不是优先考虑实现某个Ajax的特性
- Ajax 要求有足够的力量关注前端的UI展现或开发，所以对Ajax实现/框架的选择，最先要考察其客户端的实现以及提供的Web UI
看完这篇文章，我希望，2006年我们再谈起Ajax的时候，
- 作为技术人员，我不用谈论什么Web 2.0，我一样可以清楚的表达Ajax的概念
- 如果你是一个架构师，Ajax 不再是什么异步的XMLHTTP调用，不再是不刷新页面，它可以帮忙你Review应用程序的架构。
- 对于你的团队或老板来说，Ajax可以是你统一界面表现层的一个策略，同样也可能让你有了一个创建一套部门或公司级能够重用的UI类库的机会。
本新闻共
6页,当前在第
5页
1 2 3 4 5 6
