五种常见 Ajax 反模式

  • James Kao
  • Jason lai

2007 年 4 月 1 日

话题:Java.NETRuby语言 & 开发

Jack Herrington 根据自己在 Ajax 领域的开发经验,撰写了一篇文章,深入讨论了Ajax 代码中常犯的错误。他阐述了五个足以被认定为反模式(anti-pattern)的常见具体问题,总结如下:

滥用定时器(Timer)进行轮流监测。尽管 JavaScript 拥有定时器功能(通常使用 window.setInterval()),但我们只能因地制宜地使用。把它用在动画上是合理的,但对于其它方面我们就必须仔细斟酌了。最显而易见的危险信号就是使用定时器来监视请求的完成。这种情况下应该使用回调而不是轮流监测的方式。

在回调中没有检查返回结果。在使用 XMLHTTPRequest 对象的 processReqChange() 回调时,必须对回调参数的 readyState 和 status 值进行检查。回调常常会在结果完成之前被调用。假如没有检查此结果,在代码试图处理不完整数据时可能会引起错误。

在传递 HTML 更合适的情况下,传递复杂的 XML。将 XML 格式化成浏览器中显示的 HTML 可能需要编写大量的 JavaScript,这可能导致开发人员不得不面对更多的浏览器兼容性问题。

就和你做所有事情一样,到底该在服务端还是客户端处理的选择应该根据工作的需求而定。在这种情况下,举一个相对简单的例子:给出一个电影列表。如果工作更复杂一些的话——可能包含排序,添加或删除,或者进行动态交互,在点击某个电影的时候显示更多的信息——那么在客户端将包含更复杂的代码。实际上,在本文结尾,我将演示如何对在客户端排序,探讨将负载过多地置于服务端的驳论。

在该传递 JavaScript 代码时,传递 XML。简而言之,在你可以使用JSON时不要用 XML:

这里的好处是显而易见的。在本例中,使用 JavaScript 语言客户端下载的数据量节省了 52%,并且性能上也得到提升,读取 JavaScript 版本速度快了 9%。尽管 9% 看起来并不多,不过要注意的是这个例子还尚未完善。更为庞大的数据块或者更复杂的结构将会带来更多的 XML 解析代码,而 JavaScript 则会保持不变。

在服务端进行过多处理。简单的单页面功能,如表格排序,在 JavaScript 中处理起来比服务端处理得更快,效率也更高。

Java.NETRuby语言 & 开发