带有深层树状导航的应用程序通常是一个噩梦。在大多数情况中简单平直的拓扑结构以及搜索/标记可以很好的工作。但是如果一个应用程序真正使用深层树状导航，使用JavaScript来管理拓扑ui(userinterface用户接口)，则使用Ajax懒加载深层数据可以降低服务器的负载。举例来说，为了阅读一个只有一行的结果来加载整个一个新页面是非常耗时的。

实时用户对用户通讯

在一个允许用户创建实时讨论的信息公告系统中，迫使用户一次又一次的更新完页面看到答复是非常愚蠢的。回复应该是实时的，用户不应被迫总是去痴迷于刷新操作。即使是gmail这个已经对以前像hotmail/yahoomail的收件箱刷新，刷新收件箱标记的操作有所改进，也并没有充分的使用Ajax的功能来提示有新邮件到达。

投票、是否选择、等级评价

如果Ajax提交过程没有一个协调的UI提示是非常糟糕的，通过使用Ajax来提交一个调查或是否选择可以减少提交过程等待的痛苦。通过减少点击的等待时间，Ajax应用程序变得越来越有交互性，如果要用40秒来提交一个投票，除非非常在意的话大多数人会选择放弃。如果只花1秒呢，非常大比例的人会乐于参加投票的。

过滤和复杂数据操作

应用一个过滤、按日期排序、按日期和姓名排序、打开或关闭过滤器等等。任何一种高交换型操作应该交给JavaScript来处理而不是通过向服务器来提交一系列的请求。在查找或者操作大量数据的时候带来的视图上的改变最多不会超过30秒，Ajax真的使这些操作加速了。

普通录入时的提示/自动补齐

一些软件JavaScript是擅长于帮助用户完成键入相同的文字或可以预测的文字的工作的。在del.icio.us和Gmail中该功能是非常有益的，可以用来快速增加标记/email等。对于一个频繁使用的应用程序诸如网页邮件客户端或博客阅读器来说，用户有充足的时间来学习如何使用新的UI概念但是他们却无法接受一个非常缓慢的反应速度。这种应用为Ajax变的更加普及起到了一个完美的杠杆作用。随着用户使用频率的增加，更多的Ajax部件应该加强用户的使用体验。但是对于网页应用程序来说，把每件事甚至任何事都用JavaScript来实现也是没有意义的。Ajax只是针对一些特定的环境才能带来显著的帮助。在Ajax出现之前网页应用程序已经可以工作的很好了并且目前在网页开发中Ajax还存在着许多的缺陷和缺点。就算不从服务器端取得一个异步的信息数据流一个平直的html网页日志也可以工作的很好。对于文档或文档之间的跳转来说，老旧的纯HTML仍然是最好的选择。简单或很少使用的应用程序就算不用JavaScript同样可以很好的工作。

下面是一些不应该用到Ajax的地方：

简单的表单

就算表单是Ajax技术的最大受益人，一个简单内容的表单，或提交订货单，或一次性的很少用到的表单都不应该使用以Ajax驱动的表单提交机制。总的来说，如果一个表单不是很长用，或已经工作的很好，那么就算使用Ajax也没有什么帮助。

Ajax 挑战危机
对程序员而言，开发Ajax应用最头痛的问题莫过于以下几点：

Ajax在本质上是一个浏览器端的技术，首先面临无可避免的第一个问题即是浏览器的兼容性问题。各家浏览器对于JavaScript/DOM/CSS的支持总有部分不太相同或是有Bug，甚至同一浏览器的各个版本间对于JavaScript/DOM/CSS的支持也有可能部分不一样。这导致程序员在写Ajax应用时花大部分的时间在调试浏览器的兼容性而非在应用程序本身。因此，目前大部分的Ajax链接库或开发框架大多以js链接库的形式存在，以定义更高阶的JavaScriptAPI、JavaScript对象（模板）、或者JavaScriptWidgets来解决此问题。如prototype.js。

Ajax技术之主要目的在于局部交换客户端及服务器间之数据。如同传统之主从架构，无可避免的会有部分的业务逻辑会实现在客户端，或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器，且以不同之程序语言实现，这导致Ajax应用程序极难维护。如有使用者接口或业务逻辑之更动需求，再加上前一个JavaScript/DOM/CSS之兼容性问题，Ajax应用往往变成程序员的梦靥。

针对业务逻辑分散的问题，Ajax开发框架大致可分为两类：

将业务逻辑及表现层放在浏览器，数据层放在服务器：因为所有的程序以JavaScript执行在客户端，只有需要数据时才向服务器要求服务，此法又称为胖客户端（fatclient）架构。服务器在此架构下通常仅用于提供及储存数据。此法的好处在于程序员可以充分利用JavaScript搭配业务逻辑来做出特殊的使用者接口，以符合终端使用者的要求。但是问题也不少，主因在：

第一，JavaScript语言本身之能力可能不足以处理复杂的业务逻辑。
第二，JavaScript的执行效能一向不好。
第三，JavaScript存取服务器数据，仍需适当的服务器端程序之配合。
第四，浏览器兼容性的问题又出现。有些Ajax开发框架如DWR企图以自动生成JavaScript之方式来避免兼容的问题，并开立通道使得JavaScript可以直接叫用服务器端的Java程序来简化数据的存取。但是前述第一及第二两个问题仍然存在，程序员必须费相当的力达到要求。

将表现层、业务逻辑、及数据层放在服务器，浏览器仅有使用者接口引擎（UserInterfaceengine）；此法又称为瘦客户端（thinclient）架构，或中心服务器（server-centric）架构。浏览器的使用者接口引擎仅用于反映服务器的表现层以及传达使用者的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理，根据业务逻辑来更新表现层，然后反映回浏览器。因为所有应用程序完全在服务器执行，数据及表现层皆可直接存取，程序员只需使用服务器端相对较成熟之程序语言（如Java语言）即可，不需再学习JavaScript/DOM/CSS，在开发应用程序时相对容易。缺点在于使用者接口引擎以及表现层通常以标准组件的形式存在，如需要特殊组件（使用者接口）时，往往须待原框架之开发者提供，缓不济急。如开源码Ajax开发框架ZK目前支持XUL及XHTML组件，尚无XAML之支持。

Ajax是以异步的方式向服务器提交需求。对服务器而言，其与传统的提交窗体需求并无不同，而且由于是以异步之方式提交，如果同时有多个Ajax需求及窗体提交需求，将无法保证哪一个需求先获得服务器的响应。这会造成应用程序典型的多程序（process）或多线程（thread）的竞争（racing）问题。程序员因此必须自行处理或在JavaScript里面动手脚以避免这类竞争问题的发生（如Ajax需求未响应之前，先disable送出按钮），这又不必要的增加了程序员的负担。目前已知有自动处理此问题之开发框架似乎只有ZK。

Ajax 相关词条
MYSQL IP ICP ALEXA PR SEO CGI FSO FTP POP3 WCM ECM FLASH WEB GPU CPA DIV CSS HTML BBS .NET XML AJAX MD5 Ajax

1、 ajax之家
2、 jQuery中文社区
1、
2、
3、?typeid=119

回答者：warm10148 - - 提交时间:2009-11-15 6:30:00