上次说到“HTML + AJAX + WebService = C/S or B/S?”，我说通过WebService方式调用会不会又让B/S变得类似C/S了，不过结果是Client说她不能再胖，胖了Browser就不让进，呵呵……
首先第一件事就是关于DOM，有人说这才是AJAX的本质而XMLHttpRequest只是一个小工具，不过这个本质（不是McDull的那个本质，咔咔）的执行效率就实在不怎么样，不至于很差，但是你绝对不能把以前用ThickClient的Native Code所做的东西完全交给它，因为太多了你就会发现它忙不过来。
举个CSDN上见到过几次的一个例子，就是做一个类似Google Suggest那样的有筛选功能的ComboBox，遇到问题的人都说那东西只要待筛选项超过5K就没效率了，然后我说不要用DOM来构建下拉的内容而改用拼接HTML同时只有当用户超过500ms没按键时才筛选，结果有所改善，不过可能也无法处理超过10K的待筛选项。
我自己也做过一个动态生成table的东西，用DOM构建table的话一个50*30格的就要300ms~500ms，这个效率实在太低啦。
第二个问题就是复杂的客户端调用规则。例如我有一个用户注册表单要调用服务器端的3个WebMethod：
bool IsUsernameDuplicated(string Username) //用户名是否已被使用
bool IsEmailDuplicated(string Email) //Email是否已被使用
void SignUp(...) //把所有注册信息提交到数据库
现在要求异步调用IsUsernameDuplicated和IsEmailDuplicated，我也不知道哪个先返回，但必须两个都返回false才调用SignUp，任何一个返回true或者Timeout了都不调用SignUp。这样事情就会变得很麻烦，前两个WebMethod返回时必须作标记，然后用一个定式执行的程序不停的检查这两个标记直到都有返回（或者Timeout）为止。
当客户端有一系列复杂的调用规则时，问题就更加复杂了，所以最后你会发现还是不要在客户端搞复杂调用好，这些规则应该都交给服务器端处理，然后封装为一个WebMethod。例如应该只设置一个SignUp，调用时通过返回一个int来表示用户名/Email是否已被使用，又或者用Atlas的Exception机制来返回这个。
简而言之，Client跑Browser的Scripting跑道上时别给太多或者太复杂的东西它干，它根本干不来，事情还是尽量让Server包办好了。不过也有例外的时候，例如那边Flash就在大喊我很Rich（因为它自己叫自己RIA），我可以负责很重的UI任务，呵呵……
没有评论:
发表评论