2006年3月24日星期五

Client 说她的瘦身计划不能变,所以 Server 你必须再胖些

上次说到“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任务,呵呵……

没有评论:

发表评论