中国人有个毛病，爱看热闹。街边吵架了必然扫上一眼看看ko结果。

　　职业能改变人的思想，顺便牵扯点作为人的行为。咱就是搞 java应用开发的也就好这口。有什么新鲜玩意都要试把试把。有些时候真的不是因需要而去应用，就像去街边看人pk突个新鲜。ajax近来吵的很火所以很多中国人也都愿意以身试法。试图参透其奥妙所在。新鲜嘛！但这种激情往往使人忘记了理智。激情是要建立在理性的基础上才能发挥其最大作用。这点思想如果忘却，不失为大错。

　　其实你选择他如果自己做实验或玩玩几个小case还是可以，也是比较让人赞同。这说明你这个人有探索精神。有进取心，是个人才。总比很多一无事处的混混强得多。而如果不分青红一贯的应用于真实的高用户高并发量的系统项目中，恐怕是个不明智之举，仅代表个人意见。因为我也是参照其作用、利用其长处、杀敌人于无形。孙子是个很厉害的人为什么人家研究兵法多少年都不会落伍。那是因为他抓住了事物的本质。就像我们做软件应用业务原型就对系统建模型一样。因为其稳固必然长久，这是道理。我们想让自己的项目不至于最终落魄到只能大范围架构级的重构，不如选择放弃。因此当做决定前应该尽量想到前因后果，方之上上策。

　　你要看热闹，是什么驱动你去看这次热闹。这需要分析。如果根据场景不同你发现打架的人是你的朋友亲戚。你必然参与这次活动。

　　你要使用ajax，是什么驱动你去使用它。我们分析。我们不是为了用而用。而是为了发挥其作用而用。如果将其作用发挥到我们的业务中，这才是次有意义的活动。

　　我们设计，在什么地方应用。不能一味的应用。选择性的应用发挥其长处、弊其短处应该是好的选择。

　　以下为应用设计时的参考资料：

　　【导读】本文简述了Ajax技术适用场景、Ajax不适用场景的具体情况以及应用时候存在的一些问题。

　　Ajax适用场景

　　1.表单驱动的交互

　　传统的表单提交，在文本框输入内容后，点击按钮，后台处理完毕后，页面刷新，再回头检查是否刷新结果正确。使用Ajax，在点击sunmit按钮后，立刻进行异步处理，并在页面上快速显示了更新后的结果，这里没有整个页面刷新的问题。

　　2.深层次的树的导航

　　深层次的级联菜单（树）的遍历是一项非常复杂的任务，使用JavaScript来控制显示逻辑，使用Ajax延迟加载更深层次的数据可以有效的减轻服务器的负担。

　　我们以前的对级联菜单的处理多数是这样的：

　　为了避免每次对菜单的操作引起的重载页面，不采用每次调用后台的方式，而是一次性将级联菜单的所有数据全部读取出来并写入数组，然后根据用户的操作用 JavaScript来控制它的子集项目的呈现，这样虽然解决了操作响应速度、不重载页面以及避免向服务器频繁发送请求的问题，但是如果用户不对菜单进行操作或只对菜单中的一部分进行操作的话，那读取的数据中的一部分就会成为冗余数据而浪费用户的资源，特别是在菜单结构复杂、数据量大的情况下（比如菜单有很多级、每一级菜又有上百个项目），这种弊端就更为突出。

　　如果在此案中应用Ajax后，结果就会有所改观：

　　在初始化页面时我们只读出它的第一级的所有数据并显示，在用户操作一级菜单其中一项时，会通过Ajax向后台请求当前一级项目所属的二级子菜单的所有数据，如果再继续请求已经呈现的二级菜单中的一项时，再向后面请求所操作二级菜单项对应的所有三级菜单的所有数据，以此类推……这样，用什么就取什么、用多少就取多少，就不会有数据的冗余和浪费，减少了数据下载总量，而且更新页面时不用重载全部内容，只更新需要更新的那部分即可，相对于后台处理并重载的方式缩短了用户等待时间，也把对资源的浪费降到最低。

　　3.快速的用户与用户间的交流响应

　　在众多人参与的交流讨论的场景下，最不爽的事情就是让用户一遍又一遍刷新页面以便知道是否有新的讨论出现。新的回复应该以最快的速度显示出来，而把用户从分神的刷新中解脱出来，Ajax是最好的选择。[next]

　　4.类似投票、yes/no等无关痛痒的场景

　　对于类似这样的场景中，如果提交过程需要达到40秒，很多的用户就会直接忽略过去而不会参与，但是Ajax可以把时间控制在1秒之内，从而更多的用户会加入进来。

　　5.对数据进行过滤和操纵相关数据的场景

　　对数据使用过滤器，按照时间排序，或者按照时间和名称排序，开关过滤器等等。任何要求具备很高交互性数据操纵的场合都应该用JavaScript，而不是用一系列的服务器请求来完成。在每次数据更新后，再对其进行查找和处理需要耗费较多的时间，而Ajax可以加速这个过程。

　　6.普通的文本输入提示和自动完成的场景

　　在文本框等输入表单中给予输入提示，或者自动完成，可以有效的改善用户体验，尤其是那些自动完成的数据可能来自于服务器端的场合，Ajax是很好的选择。

　　Ajax不适用场景

　　1.部分简单的表单