2006年3月30日星期四

ASP.NET 2.0解决了Code-Behind需要控件声明同步的问题

这显然是一个非常明智而且很早就应该实现的做法,因为已经在HTML中声明为runat="server"的控件,就应该算是声明过,还要在code-behind中同步的用C#代码再声明一个同名控件显然是违反了《程序员修炼之道》中所谓的DRY(Don't Repeat Yourself)原则。

原本ASP.NET 1.x的编译模型是编译站点时先编译code-behind部分,然后得到code-behind部分的Page派生类,等到运行时再编译aspx部分此事得到code-behind部分的派生类(也就是Page的二级派生类),而一旦aspx和code-behind出现控件声明的不同步那么这个继承关系将出现问题。

ASP.NET 2.0的做法就是把aspx和code-behind都看作Page派生类的partial class,并且合成编译,而aspx中所有的控件声明都将在编译时自动转换为C#声明,这样的好处是只有一层Page派生类而且不用同步什么东西,所有东西都是仅声明一次。不过有一个问题就是,到底aspx中的声明是转换为C#的partial class再编译还是能够直接编译呢?转换为C#编译是很直接的思路,ASP.NET 2.0 的内部变化也是说原本由VS.NET 2002/2003做的声明同步工作现在交给ASP.NET Runtime了,但是这样就有一个问题,如果要开发一种新的ASP.NET语言(例如Delphi for ASP.NET 2.0),那么也就必须建立aspx到该语言的翻译,这是十分麻烦的事情。但是如果aspx和code-behind分开编译的话,这好像超出了partial class的能力范围,根据C# 2.0的规范,partial class的所有部分必须是同时编译的,不可以是增量编译的,也不可以是跨语言编译的,而aspx和code-behind都直接编译的话就需要双语言编译,也就需要增量编译。

ASP.NET 2.0还有一个很好的地方,就是部署编译,你能够把整个网站都编译了(包括aspx和code-behind)然后发布,发布目标的aspx将是一个仅引用后台类的控文件,这样性能最好而且也不用担心代码泄漏(特别是编译后的dll再混淆一下的话)。不过因为aspx部分也编译了,所以这样发布的网站发布之后就不能改动。而ASP.NET 2.0还提供另一个极端,就是完全运行时编译。以前ASP.NET 1.x如果是code-behind的话,code-behind部分就必须在VS.NET里面先编译,不过现在ASP.NET 2.0能够自动监测code-behind部分是否有改动过(甚至是/App_Code目录下的其他非UI逻辑的code),如果有就运行时编译,这对于调试来说是挺方便的,不需要每次调时前先在VS.NET里面按Ctrl+Shift+B编译。

2006年3月27日星期一

关于中学是否应该教Office应用

Jim跟我说,中学花时间去教Office,还不如教程序设计锻炼一下思维能力。不过最近Piggest却提了一些排版问题,显然不上课那些功能就在二级菜单你也不知道它原来是这样用的。

Office这件东西,有人说只有5%的功能常用,95%的功能常人用不到,所以作为一个聪明的开发商就应该把主要精力花在优化着5%常用功能的易用性上,这是非常合理的。问题是,要完成一份Document所需要的成本是全局的,假如5%常用功能的使用成本很低,但是偏偏你要用到几个5%以外的功能而它们的使用成本非常高,那么无论MS如何优化那5%的功能对此都毫无帮助。例如,很可能你不知道插入分页符,然后通过手动插入回车来实现分页,结果你用20min输入完文章,然后花了10min来分页,但之后你每次改动文档时需要手动调整分页的时间和输入改动的时间是1:1,那么显然输入和分页所花费的时间将趋于1:1,即使输入部分(作为常用功能)优化得很好你做得很快,最终生成Document的成本还是被分页而卡得很高。

降低你用非5%常用功能时的成本,唯一途径就是你接受过比较系统的学习。就好像Piggest去上Maya培训那样,就好像我说学Javascript要必须看O'Reilly的《Javascript权威指南》一样,不经过系统学习那些非常用功能你是不会知道的,这时候那些非常用功能你就只能用常用功能去“模拟”,这时候使用非常用功能的成本就会暴增。很多东西称之为“易学难精”正是因为非常用功能自己学难以了解到,甚至系统教材也没有,只有长期钻研的高手才对该领域有所了解,例如ASP.NET的页面生存周期的细节,MS不肯公开细节,于是就出现了个高手自己用Reflector看ASP.NET源代码和自己做实验然后把结果公布到自己的Blog的现象。

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任务,呵呵……

2006年3月22日星期三

Benny说不要太早走出社会喔~

上次回去修华附论坛那台服务器时,Benny说第二天就要面试20个本科生,从中要两个,试用期月薪¥1K+,转正后再加¥500。然后我问他招那两个人的工作范围是什么,他说一个负责发布新闻,长期坐在网络中心,另外一个跟吴老师东奔西跑(估计是维修类的)。

Benny的意思就是,能够留在学校里,最好就一直留在学校里不要出来。不过留在学校里虽然什么都好,但是现在好的学校都越来越“敛财”了,所谓教育产业化搞到学校也变成了服务运营商,能够骗到一点钱就骗一点,积累资金“扩大生产”,真正专心搞教学或者研究的人又剩下多少呢?

2006年3月19日星期日

Site moved~

由于sitesled已经有一段时间无法进行FTP上传了,所以改到5000megs,PURL保持不变:
http://purl.oclc.org/NET/cathsfz

由于原来用开GB2312发布,现在服务器的charset为UTF-8,改过来可真不容易。用GB2312发布,则客户端打开时自动根据HTTP的charset而不是HTML的charset设置为UTF-8,用户需要手动改回GB2312才能正常浏览;用UTF-8发布,根本就是乱麻,因为Blogger保存文章和模板时就有charset属性,GB2312的文章按UTF-8发布无论如何都是乱码。

最后我意外找到了解决方案,就是先用GB2312完整发布一次,然后改用UTF-8发布,并把模版和首页上的几篇文章改为UTF-8,最后仅发布索引一次,那就OK了。这个解决方案首先解决了首页显示问题(这是我原本的目标),后来发现打开内页竟然GB2312又能自动识别(难道仅访问/时HTTP协议会返回charset),所以暂时我的Blog“看起来”完全没问题。

2006年3月5日星期日

My Life Rate~

This Is My Life, Rated
Life:
5.6
Mind:
6.2
Body:
5.5
Spirit:
6.3
Friends/Family:
5.9
Love:
1.5
Finance:
5.5
Take the Rate My Life Quiz