以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)

早在ASP.NET AJAX从CTP转向Beta再转向RTM时，看着客户端的Control被逐步放弃，与此同时ASP.NET AJAX Control Toolkit越来越多地使用Behavior，我就想深入说说ASP.NET AJAX的模式。不过由于我比较懒，所以这个话题只在《理想的 ASP.NET AJAX (Part 2 - Server Centric)》中一笔带过，没有深入讨论。今天看到volnet的《我们究竟是否有在“Asp.net中模仿Winform的MessageBox ”的必要？》，决定写一个文章系列来说说ASP.NET AJAX的模式。

什么是Behavior？

什么是Behavior？Behavior与Control有什么不同？这是首先需要回答的问题。

在Windows开发当中，Behavior的概念是不存在的，有的只是Control。ASP开发连Control都没有的，到了ASP.NET才引入了Control的概念。为什么Ajax开发要引入Behavior这样的概念呢？因为Behavior意味着不需要改变原有的组件逻辑，而改变原有组件的逻辑在客户端往往是不可行的，至少是难以实现的。

举个最简单的例子，一个<input type=”text” />就是一个浏览器内部的对象，你无法扩展这个对象的类型，也无法为它加上新的属性与方法，至少并非所有浏览器都允许你在JavaScript中这样做。然而如果你想要让它加上auto-complete（或曰suggest）的功能，这是可以做到的，并且很多人都做过了，例如ASP.NET AJAX Control Toolkit的AutoComplete，或者是script.aculo.us的autocompleter。这些实现都基于同一种方式，就是尝试基于input已有的接口在它之外添加新功能，而非尝试继承input并在它之内添加功能。

类似的做法在Ajax开发中普遍存在。例如说拖放吧，现在离HTML5拖放的全面普及不知道还有多远，所以大家都只能基于现有的鼠标事件来开发拖放功能。又或者说带有验证功能的输入框，无论是input还是select，无论是客户端验证还是服务器端验证，也都是基于现有HTML元素的事件来完成的。这一切都是Behavior。

什么情况下使用Behavior？

简单归纳，就两个条件：

1. 需要基于特定的一个组建进行扩展
2. 组建本身所处的环境缺乏可扩展性

单看第1个条件，我们有丰富的选择。很多人的第一反应就是继承自该组件，把扩展功能做到子类里面。熟悉设计模式的话，可能还会想到decorator pattern。然而在浏览器的环境当中，受到第2个条件的限制，继承或者decorator pattern都是不可行的。这时候，我们就需要使用Behavior了。

在一定程度上，我们可以把Behavior看作一种折衷了的decorator pattern。在decorator pattern中，decorator也继承自组件，因此当一个组件使用decorator pattern后，我们就把decorator放在原组件所处的位置上，而原组件就成了decorator的一个子节点（基于树的角度来看的话）。如果再加一个decorator，原decorator就会如同一个普通组件那样再被封装一次。在多个decorator的情况下，decorator之间是串联的关系。Behavior本身不是一个浏览器内部的组件，它无法继承自input的基类，因此Behavior也不能串联。Behavior本身本也不会取代input在树中的位置，这使得Behavior可以并联起来——一个input可以有多个Behavior，例如一个是自动完成，另外一个是输入验证。

总之，如果你原来的工作就是和UI打交道，并且熟练使用decorator pattern，那么在进行Ajax开发时把decorator pattern换成Behavior就可以了。

小结

回过头来看文章开头所说的MessageBox（或曰confirm）的问题，如果这个功能不需要对服务器端进行反馈，完全可以使用Behavior实现。ASP.NET AJAX Control Toolkit就有ConfirmButton这样一个东西，在客户端叫Behavior，在服务器端叫Extender，其实Extender就是对Behavior在服务器端做一下封装而已。当然，ConfirmButton不能完全实现MessageBox的功能，它只能在用户选择“取消”时取消整个提交操作，但不能够执行另外一个服务器端的代码分支。这算是Behavior的一个限制，就是它只能在客户端添加额外的功能，但是它不能影响到与服务器端的交互。但很多时候，正是这种限制确保了我们开发的组件是与服务器端解耦的。

如果我真的需要一个与服务器端交互的客户端组件，例如支持调用服务器端代码分支的confirm，怎么办？这时候你就真的需要一个与服务器端Control对应的客户端Control了。请关注本系列的下一篇文章，《以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 – Control)》。通过订阅feed，你可以及时获得文章更新：

• Cat in dotNET (feed)
• Cat in Chinese (feed)

P.S.既然提到了Behavior和Extender的一一对应关系，就不得不说一下，服务器端的Extender就是真正的decorator pattern。

远离国内的 SNS

最近我一直在想是否要把海内的帐号终止掉，原因只有一个——我很久不上海内了。既然我不用它，我就没必要把我的个人信息放在上面，让更多不认识的人有机会获取到这些信息。

如果要详细解释这件事，就要从很久很久以前说起，就是海内刚刚开放注册的时候。在改为邀请注册之前，海内曾经开放注册过几天，让及时获得消息的geek们第一时间获得了帐号，那时候我还没有多少好友在上面，已有的好友没有多少活动，news feed自然不值得一看。

后来，海内上的好友逐渐多起来了，大家也更活跃了，这是我认为海内最好的一段时候了。虽然，这时候的news feed算法也不怎么样，例如不会把同类项合并了，也不会对信息按照重要程度进行过滤。我之前也说过，Facebook的真正价值就在于它的news feed，news feed的算法不行也就以为着海内能为用户带来的价值优先。

随后，海内开始把重心转移到游戏开发上来。买卖好友可以说是为了刺激用户数量的扩张，但越来越多的游戏上线让我觉得整个海内都变得以娱乐白领为首要目标了。我的个人观点是跟Bean和Awflasher差不多，虽然中国人口众多必然导致劳动力过剩，但让每个人都把自己过剩的劳动时间投入到游戏当中并不是好事情。当海内的news feed充斥着各类游戏相关的信息时，我就不再去看海内了。

说完了海内，国内的其他SNS我想也没必要一一列举了。海内曾经是国内最用心用力想称为白领SNS的一个了，国内其他成功SNS的目标从一开始就定为娱乐性SNS，短期内不可能得到比海内更有价值的结果。在这里我所说的价值不是指SNS本身的商业价值，而是指推动国内SNS用户素质提升的价值，是指创造SNS之外的商业价值的可能性。

China MVP Open Day 2008

一年又过去了，去年的MVP Open Day在三亚，今年改成了在北京，我甚至连飞机也不用搭了，只需要打的参加（也要¥99）。

我是17号晚上和飞飞一起从中关村打的去汤山的。Bean则是当晚深夜飞过来，很可惜Bean不知道联合航空到北京的飞机是停南苑机场的，结果从南苑机场打的到汤山还费了他不少时间和金钱。Dflying早些时候就飞来北京了，不过不知道去哪里玩了，竟然18号晚上不到酒店让我一人独占房间。18号晚上去到后，人都散了，只是见到了Sisley、Eddie等人在筹备第二天的晚会，当然还有排舞的老葛等人。

由于晚上看Wanted看到凌晨两点，18号一起来就赶去吃早餐，接着就见到了Mango和Bean。由于我第一天晚上没有签到，吃完就马上赶去签到领衣服——没办法，早上的keynote规定大家要穿统一的衣服。keynote上讲了很多东西，还颁了奖——就是MVP每年一块的水晶座，今年是奥运年所以是火炬造型的水晶座——不过整个早上最让大家兴奋的应该就是那台Surface了。据说中国只有一台Surface，放在MSRA，估计就是那一台了，现在拿来向我们展示WPF如何开发Surface应用程序，keynote之间我们就都冲上台玩这台Surface顺便拍照。

中午的午餐组织得有点混乱，实际上整个MVP Open Day都组织得比较混乱，不知道是不是因为会务外包了给CSDN。据说因为会务很赚钱所以CSDN现在热衷于做这个，不过确实不太专业。

接着就是下午的一对breakout session了，不过没有哪个我特别感兴趣的——完全没有ASP.NET或者Silverlight的session嘛……我和Bean在户外找了个地方坐下来上上网聊聊天，后来俞晖也加入进来了，包包跑过来和我们照相，Dflying说公司有事要立即赶回上海（他还真没在酒店住过一晚）……整个下午我就没有专心听过一个session，都是周围跑去见别的MVP。

午餐按照技术特长来分组，晚餐就是按照地区来分组，俞晖和紫柔跑来我们广东桌装广东人，俞晖还是忘记不了说他喜欢吃螃蟹并且对于没有螃蟹感到可惜。我则一再要求紫柔把我从Web版主调回ASP.NET版主，因为当初无拉拉被分到Web版主实在让人郁闷，大部分IIS、IE之类的问题我都无法回答上来，也不确认其他人的回答是否正确。

晚餐之后就是晚会了，一个半小时其实不算长，不过留下更多时间给MVP交流也是对的，随后就是博客园的MVP聚会。在博客园上的大部分MVP都来了，没来的据包包统计大多都是上海的，例如Jeffery Zhao——我很好奇他所谓的减肥成功到底是什么效果，可写他就是不出现。博客园的聚会，就是大家各自自我介绍，然后分组讨论，晚上黎波来了——他虽然没有MVP连任成功，不过刚好也在北京为Microsoft的客户部署项目——我就和他聊了一下Sharepoint。回到房间之后，我叫了Bean过来聊天，不过没聊到什么他就回去睡觉了。

19号早上是拓展训练，就是盲人方阵和毕业墙两个项目，我们组做得还不错。中午吃饭后就是期待依旧的参观鸟巢了——其实我一直不认为鸟巢如何如何特别，不过倒还是个很值得拍照的地方。一群MVP搭大巴来到鸟巢，被告知水立方和玲珑塔都不对外开放了，于是只能进入鸟巢参观。整个广场确实很大，不过设计确实不怎么样，很多地方都很不人性化——鸟巢很多长长的楼梯，出去少数电梯后竟然没有扶梯，这叫来自发达国家习惯走到哪都是扶梯的人怎么适应呢？整个广场那么大，座位放了很多但就是不见洗手间，垃圾分类就不要期望了因为连垃圾桶都是那种很丑陋带轮子的。简单来说，看看鸟巢就知道典型的北京本地价值观了——很追求体积上的庞大，或者说是“排场”，但是不注重细节，也不懂得什么叫人性化。

参观完鸟巢后，拍了几张集体照就解散了，去机场的、去火车站的、直接回家的……基本上都涌进了地铁站，然后各自超自己的方向走。

有空要做个 Theme Software Corp 的游戏

当年Theme Hospital的搞怪实在让人怀念。各种奇特而富有创意的病症，与之配合的神奇治疗方法，还有行为略显怪异的医生和护士，组合起来是那么的有趣。现在在IT公司中的生活，感觉也很有趣，虽然有些事情也挺烦人，不过却是不错的谈资。

将来如果有时间做游戏，就做一款Theme Software Corp。市场是有各种奇怪的需求，然后要请PM来做研究并得出产品开发计划，再要请SDE来开发，之后还要请SDET来提高质量。为了保证这群人的满意度，和招聘到更加高级别的人员，必须购买各种设备来满足他们奇怪的生活需求，从咖啡机到按摩椅，还有Wii、XBox360或者PS3，甚至自己建移动大厦加一个游泳池。结果发现这些人每天来到就去拿咖啡或者可乐，然后开始看看feed，最后工作一会儿又闪出吃饭了。你想尽办法利用他们的才能，但是innovation的发挥却是很不稳定的，项目不停delay士气下降，你又要投资点什么来补救。

总之，这个游戏应该继承Theme Hospital的一些关键特性，游戏中的各种事件都是很无厘头的，同时你又要努力balance游戏中不同的指标——正如Dreaming in Code中说到的质量三角，时间、金钱、特性三者不可能都得到，在追求其中一个的时候必然削弱另外的两个。这样在有相当游戏难度的同时，又有娱乐性可言。

最糟糕的一次飞行经历

星期天晚上从广州飞北京，登机和下机的安排都极差！

在广州白云机场的B区登机，又是一层登机口，意味着肯定是搭摆渡车的。开头以为好像上次那样，飞机是国际航班转飞国内，所以停在A区空地了，结果还真是这样，而且还不是停在A区空地——是泊在A区登机桥边了！那天广州暴雨，如果飞机停在空地，登机专用车是有遮顶的，这样登机还不至于淋湿。但飞机泊在登机桥边了，就要从地面爬上登机桥（我终于知道登机桥边的楼梯有什么用了），楼梯是没有遮顶的，所有人都是淋雨之后才走进飞机的。

到了北京首都机场后，被告知地面在调整停机位，要重新分配机位后才能下机，然后飞机就停在了机场空地上足足等了30分钟！不知道乘客与空姐吵起来是否有推进作用，最后停机位并没有怎么“分配”法，飞机就在原地把我们放下，然后让摆渡车接我们走。浪费那么多时间才出摆渡车，一早这样做不就好咯，机场的调度真是差。

什么时候才能在网上收到广州和香港的节目呢

Sean O'Driscoll的一条tweet，说能够在网上听到Seattle的电台感觉离家里近了，让我再次想起如何能够在北京接受粤语节目的问题。

在北京最郁闷的事情，暂时来说，就是无法接收到任何广州或者是香港的节目，无论是电视还是广播。试用过很多P2P的网络电视平台，暂时来说最满意的就是TVU收看凤凰卫视了，至于TVB——虽然有人转发到网络上，但是peers太少，从来没有成功看到过，就是见到list上面有TVB的名字。

关于接收TVB，Catfish总是建议我接收卫星信号，因为他以前在北大就是负责把信号送上卫星的。但是这个方案对我来说也太不现实了——我连电视机都没有呢！我从来只有电脑，电视对我来说是多余的，所以在北京租的房子自然不会买电视。

除此之外，还有别的办法吗？我不停地问身边的人这个问题，但一直没有找到有效的解决方案。