读书笔记:ASP.NET使用代码隐藏页是否更好

资深ASP.NET开发者Stephen Walther在《ASP.NET 3.5 Unleashed》中说到:
“I’ve heard it argued that code-behind pages are superior to single-file pages because code-behind pages enable you to more cleanly separate your user interface from your application logic. The problem with this argument is that the normal justification for separating your user interface from your application logic is code reuse. Building code-behind pages really doesn’t promote code reuse. A better way to reuse application logic across multiple pages is to build separate component libraries. (Part IVof this book explores this topic.)
My personal preference is to build ASP.NET applications using single-file ASP.NET pages because this approach requires managing fewer files. However, I’ve built many applications using the code-behind model (such as some of the ASP.NET Starter Kits) without suffering dire consequences.”
 
大致意思为:
“我听到一种论调说代码隐藏页比单一页面更高级,因为代码隐藏页可以清晰地隔离用户界面与应用逻辑。该问题症结在于,用户界面与应用逻辑隔离的原因是为了代码重用。构建代码隐藏页并不会提高代码的重用。比较好的重用应用逻辑的办法是把多个页面构建成一个独立的组件库。
我个人构建ASP.NET应用程序的偏好是使用单一的ASP.NET页面,因为这一方式减少了请求管理的文件量。不过,我在不计后果的情况下也构建过许多使用了代码隐藏页模型的应用(如ASP.NET Starter Kits)。”
 
这段话在原书中第45页。
发表在 .NET | 发表评论

IIS 7.0 限制IP访问及错误页面的自定义

遇到了这样的设置场景,小结一下。

IIS 7.0 下对指定网站限制IP访问的设置:

一、选中“网站”下的指定网站

二、点选IIS中间栏功能视图部分内的“IPv4地址和域限制”。

三、比如这里只限制IP“192.168.0.1”能访问网站,则可点击IIS右侧操作视图中“添加允许条目”。根据要求填写指定的IP地址,确认即可。

四、以上设置完成后,在实测时可以发现并未实际生效,还需要在右侧操作视图中选择“编辑功能设置”,设定“未指定的客户端访问权限”为“拒绝”。确认后可生效。

此时访问指定的网站,如果浏览器所在客户机IP不是“192.168.0.1”,那么看到的就是拒绝访问的406.3出错页面。其效果很吓人,很可能会让人误以为网站出了什么严重的问题,这时就需要给访问者很友好的提示信息以改善用户体验,这就需要对系统的错误页面进行自定义。

一、选中IIS管理器“网站”下的指定网站

二、点选中栏功能视图中的“错误页”

三、点击右侧操作视图中的“添加”。在弹出的对话框中“状态码”项输入“403.6”,“响应操作”中可根据情况指向自定义的错误页面。

需要注意的是,如果已经配置了“为本地和远程请求返回的详细错误信息”,系统不会返回使用自定义的错误信息页面。要在“错误页”右侧操作视图的“编辑功能设置”中选择“自定义错误页”。这样做后对网站页面调试比较麻烦,不容易看到详细的错误信息了。

发表在 技术总结 | 发表评论

《Programming ASP.NET 3.5中文版:第4版》译序

3月初博文视点的徐定翔编辑告诉我说翻译可在Google Sites协作平台上进行,当时就想Google Sites原来还可以这样用。不过使用它确实省了许多沟通上的麻烦,因此我对这次协作体验印象非常深刻……

翻译前,我搭建了书中要求的系统环境,并且尽可能测试翻译中遇到的每个示例,同时在可能的情况下阅读书中建议的外部资料。这对理解原文很有效,同时还能纠正一些原文中的小错误。比如,原书第12章中曾引用了微软IIS团队所维护网站的几个链接实际却不存在,这极有可能与网站改版调整了链接形式有关。在O’Reilly网站上提出该问题后,很快就得到了回应,根据官方的勘误我修正了这个错误。O’Reilly响应颇为及时,在我写这篇序时我所提交的大部分勘误建议都得到了反馈。因此可以说,我所翻译的中文版内容已经修正了英文版书中所有已知的错误。

为求证某个专用词汇的准确译法,我常去MSDN中文版页面海量文档中检索相关信息。在第13章遇到过一个词“Breadcrumb”,如果直接用“面包屑”来翻译,肯定会有很多人对上下文意思不知所云。在寻找了一些资料后也终于理解了作者为什么要用这个词,但是我就是在中文中找不到对应的词语来翻译它。我想这应该就是文化背景差异造成的吧。这个词的典故就出现在西方儿童的睡前故事中,他们只要一见到这个词就能明白作者想要表达的意思。但是我在向身边朋友求助帮忙翻译这个词时,需要费很多口舌才能让他们明白。最后经过反复思量译成了“面包屑导航”,至少看到这个译法能让大家知道这是一种特定的导航类型了。就是看起来这么简单的事也让我折腾了很久,翻译真是件辛苦的事。但是只要能让大家理解原文所传达的意思,辛苦也就不算什么了。

老实说,我对自己的翻译原本还是很自信的,但是当看到审校的文档中批注纵横时,不禁有点吃惊,原来还是存在很多错误的。在此对负责审校我的译稿的覃彬彬表示感谢。

3月下旬ASP.NET MVC 1.0正式版发布,当得到这个消息时我正在翻译中。但是这本介绍ASP.NET的书并没有一章专门的篇幅来介绍MVC这种将成为主流的开发技术。在本书作者成书之时,对于尚未定型的产品确实不方便多说。我理解这一点,不过这种无可奈何的事情多少让我感到有些遗憾。

有个朋友翻了翻样书问:书皮上印的是什么东东?我竟不知道如何回答,翻译了这么久却没细想过这个问题。为此,我去找了些资料研究了一下,总算了解了一些情况,O’Reilly的书似乎从很久前就开始用各种动物图片做封面,本书所用的动物形象是一种形似吉他的犁头鳐(Guitarfish)。至于该动物与本书内容有什么联系,则始终没有看到相关资料说明。根据O’Reilly曾经的说法,采用动物做封面外观是根据读者的评论。 自己的调查,以及分销渠道反馈的意见,也只是为了给枯燥无趣的技术书籍带来些生气。查阅这些资料的同时也注意到另一个有趣的事实:从本书的第一版到第四版都采用了相同的动物形象,前三版说明中都声称这是一种叫刺鳐(Stingray)的鱼,可是到本版时被改称为犁头鳐。这应该是O’Reilly公司犯的一个错误吧。翻译中遇到这样的事,也蛮好玩的。

将翻译过程中的一鳞半爪罗列于此,作为序。

邹建强
2009年7月11日于北京

——————

后记:现在Google Sites服务国内已经不能访问

发表在 .NET | 发表评论

《高性能网页开发新20条规则详解》摘要

这是应CSDN《程序员》杂志编辑邀请写的命题作文,前几天刚看看到五月份的刊物,只刊载了前半部分,后半部分将会在六月刊上出现。因为杂志还没有把原文全部刊出发行,应编辑要求我就暂时不把原文放在博客中了,这里只给出这Yahoo!优化20条规则的标题,每条规则后的方括号是指具体属于什么类别的优化。

一、尽早清除缓冲区 [服务器端]
二、使用 GET 方法的AJAX请求 [服务器端]
三、后加载组件    [页面内容]
四、预加载组件    [页面内容]
五、减少 DOM 元素数量    [页面内容]
六、分隔组件到多个域中    [页面内容]
七、尽量减少 HTML 标签 iframe 的使用数    [页面内容]
八、避免404页面    [页面内容]
九、减少 cookie 大小 [cookie]
十、将组件存放在无cookie的域 [cookie]
十一、尽力减少对 DOM 的访问 [JavaScript]
十二、开发智能的事件处理程序 [JavaScript]
十三、使用 <link> 标签来导入样式文件,不要使用 @import 导入 [css]
十四、避免使用css滤镜 [css]
十五、优化图片 [图片]
十六、优化 CSS sprites [图片]
十七、不要在 HTML 中缩放图片 [图片]
十八、让 favicon.ico 文件减少大小并且可缓存 [图片]
十九、保持组件大小在25K以下 [手机]
二十、将组件打包合并到一个 Multipart结构的文档中 [手机]

现在Yahoo!的优化规则加上早先的14条已经累计有34条了。

发表在 技术总结 | 2条评论

Cacheman —— .NET架构下的分布式缓存

一个月前,fcicq邮件给我提供了一个Windows平台下的 memcached 类型的缓存软件 Cacheman。这是由微软旗下的 Popfly 项目组成员 Sriram Krishnan 的作品。是他用业余时间开发的。于是开始关注这个缓存项目。

最新的情况是,微软的 Popfly 网站已经“悄悄地”的做了更新,就是采用了 Krishnan 的 Cacheman,更新了缓存机制。该项缓存技术更新带来的性能提升非常显著,根据Popfly团队中的 John Montgomery 的说法:加载一个已有的Mashup应用时,可以带来2到6倍的性能提升。

这些说法也得到了 Krishnan 本人的确认 。他提到这是 Cacheman 的第一次的实际应用,并自豪的说 Cacheman 不费吹灰之力就拿下了 Popfly 的全部访问量。

有意思的是 Montgomery 说他很开心这玩意儿运行正常,特别在缓存的多层分布式方面考虑周到,然后他又画蛇添足的补充了一句“至少现在如此”,然后 Krishnan 调侃说“我喜欢你说‘至少现在如此’的方式”。

简单介绍一下 Cacheman 这个项目。资料主要来源于 Krishnan的博客对Cacheman的介绍

Cacheman是一个基于Windows平台的快速分布式哈希表。是由纯托管代码实现。中间搁置了有几个月,直到最近(似乎是今年1月低2月初)才开始重新上马这个项目,极可能就是因为Popfly项目需要的缘故才开始着手的。

Krishnan本人对 memcached 很感兴趣,于是创建了 Cacheman。Cacheman上有很多 memcached 的影子,比如与memcached相似的文本通讯协议。Cacheman的通讯协议公开,任何人可以根据自己偏爱的语言环境写客户端。 Krishnan 在自己家用电脑(2.4GHz Intel Core 2 带2GB内存)上进入测试,达到了每秒16000次左右的请求,并且还是服务器与客户端都是在同一台服务器下完成的。

现这款产品还不太完善,作者自身也提到:在Cacheman做指定key的GET/SET/DELETE操作时,客户端需要弄清需要与哪一台Cacheman服务器通讯,为此要对该key做一个快速FNV哈希然后求余得到应该和几台服务器中的哪台服务器通讯。但该法的缺点在于新增或删除一个服务器节点时,缓存节点需要大规模迁移。修复该问题需要一致性的哈希算法,作者表示还没有时间解决此事。作者提出了采用中心架构的“主缓存服务器”的解决办法,让客户端轮询主缓存服务器来获取应该与那个缓存服务器通讯,但他也觉的这样做增加了复杂性,会带来些新问题。

可以感觉到,由于 Cacheman 这个个人项目已经介入到 Popfly 这个正式产品中,可能很快就会被微软吸纳为正式产品,因此如果有人采用这个产品做自己缓存的解决方案的话,应该不必太担心后续的产品升级及文档支持服务,它的未来前途值的期待。说不定 Krishnan 会从 Popfly 项目脱身出来专职负责这个 Cacheman 项目。

目前最新的版本是0.0.2版 下载:http://www.sriramkrishnan.com/projects/cacheman/Cacheman_0_0_2.zip 。虽然有人希望作者把它作为一个开源项目,遗憾的很,似乎作者并无此意,目前仅提供了二进制文件。

发表在 技术总结 | 1条评论

收购Yahoo,微软错了吗

目前争论都认为微软收购Yahoo!是不明智的。就我而言,也很难把微软和Yahoo!两家公司形象等同起来。
Yahoo!对微软而言共同点似乎很少,极难整合,至少在短期内是这样,那么微软错了,但是问题在于微软直的错了吗?假如微软没有错呢?

看看微软2007年的两次大收购:
2007年5月 微软出价60亿美元收购在线广告商aQuantive 。
2007年10月 微软2.4亿美元收购Facebook的1.6%股份。

微软的收购行为已经明确表达出它认为互联网最大有盈利模式的市场是广告,互联网的斗争将围绕广告展开。收购Facebook部分股份的行为应该认为微软最主要的目的是其精准的广告服务。

同样的,回过头再来看看Yahoo!的收购。的确短期内两家公司确实很难整合,但是两家的互联网广告业务却可以联合起来对抗Google。
微软对Google在互联网广告业务的迅速发展是非常重视的。Google收购广告业务商DoubleClick公司时,引起了包括微软在内几家大型网络公司的紧张,联合指控Google搞垄断,反对其收购行为。Yahoo!同样也面对这样的压力,它和微软将面临共同的敌人。从这一点讲,这次收购就是合理的。

作为结尾,引用一下微软官方的新闻稿 http://www.microsoft.com/presspass/press/2008/feb08/02-01CorpNewsPR.mspx 中对互联广告市场的预测:
The online advertising market is growing at a very fast pace, from over $40 billion in 2007 to nearly $80 billion by 2010.

有趣的是,当年微软收购Facebook时也有类似的争论,看看这篇 关于微软入股Facebook

发表在 东拉西扯 | 发表评论

解读豆瓣的“指环王架构”

豆瓣的官方博客前几天发表了"豆瓣技术团队的指环王文化",文中笔调谐趣地道出《指环王》渗透入豆瓣的方方面面的场景,不经意间也透露出些许网站的“指环王架构”信息。我稍微做了一下整理,对有些信息做一些适当推测。

两台Web服务器承担。一台可能负责读书、电影、小组等;另一台负责9点。这两台服务器应该不是在前端的,豆瓣的网址应该都经过反向代理Rewrite过的,因此放在前端的可能还有几台硬盘缓存服务器(Squid?)做静态文件缓存,数目不详。
原文:梅里(Merry)和山姆(Sam)这两个霍比特人挑起了大梁,承担起所有用户的请求,向豆友们展现丰富多彩的页面。

应该还有几台Web服务器运行豆瓣的英文版及官方博客。不过从注册用户分离上看豆瓣英文版架构与中文版架构间关联度不大。
原文:运行着英文版豆瓣和豆瓣blog的服务器在美国,由于它离我们比较远,因此我们用中土世界跑得最快的马命名它——甘道夫的坐骑影疾(Shadowfax)。)

四台数据库服务器。这四台服务器的职能如何切分的还不清楚。如果这四台服务器是采用主从的架构,难道双胞胎爱隆和爱洛斯这两台是Slave服务器,森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)是Master服务器?呵呵,瞎猜。
原文:四个神仙级的精灵:双胞胎爱隆(Elrond)和爱洛斯(Elros),森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)用他们伟大的智慧和不死的生命保护着用户的所有数据。

一台服务器做整站的全文检索
原文:爱隆之女,美丽的亚玟公主(Arwen)帮助用户迅速搜索到想要的信息。

两台服务器做后台服务。可能是RSS抓取及爬虫搜索的服务。
原文:另一个霍比特人皮聘(Pippin)和英俊的精灵王子勒苟拉斯(Legolas)执行着一些后台任务。

三台数据挖掘服务器
原文:人皇阿拉贡(Aragorn)和刚铎摄政王的儿子波罗莫(Boromir),这两个强壮的人类和矮人金雳(Gimli)一起,承担着数据挖掘的重担。

一台图片文件服务器。以后豆瓣用户的头像、图书、电影等的图片都会由这台服务器来存储维护。从更广的方面讲,可能所有的css、js角本这样的静态文本都会被存储在这台服务器上。
原文:而波罗莫的弟弟法拉墨(Faramir)则逐步接管起图片的显示。

以上豆瓣的服务器架构的分配,实际上从这个服务器架构上还很难了解到到豆瓣如何处理负载均衡的。这里仅做初步认识好了。下面是豆瓣团队的软件开发项目。

豆瓣现有的软件项目:
豆瓣主站、数据挖掘、搜索爬虫、RSS抓取(9点)、高性能分布式计算平台。

开发:
开发团队采用了SCRUM敏捷模型的开发方法,Sprint的周期7天(周一迭代),以迅速响应不断变化的需求。每周的进展都会有一个code name。

看看以后豆瓣官方能否透露出更多的“指环王架构”细节。比如那个高性能分布式计算平台(这个名字很邪恶,叫魔多),或者一些没有提到的功能超级无敌的项目(似乎豆瓣的命名规则是越邪恶功能越强大,因此这个项目可能是未知的“索伦之眼”:-D)等等

发表在 技术总结 | 发表评论