2011年3月3日
2011年3月2日
翻完《Pro C# 2008 and .NET 3.5 Platform》
Linq章节写的非常清晰有条理,同时也对自己之前长期的理解偏差汗了一下。就在此备记一下:
1.Lambda表达式在预编译阶段就会变成泛型委托的一个匿名实体,这一点很重要,说明linq to sql并不是一撮而就直接翻译为TSQL查询的(虽然VS可以在断点模式直接为我们获取TSQL,至今我对VS依然是拜膜的心态),这也是实现查询参数《预编译linq查询》的基础
2.linq查询返回值并不是那些MSDN中的类型(如IQueryable),而是一类.NET系统级隐式类型,最常用的如where<T>返回的是一个叫做OrderedEnumerable的类,它可以隐式转换为各种可延迟执行查询的类型,如此设计是为了分离用户端(coder)与系统之间的需求耦合,在此又深刻感受到.NET平台优秀的层次设计。
3.因为查询结果的不确定性(可用静态方法封不同装数据源的相同查询逻辑),var是linq的重要组成部分,能大量简化代码,但在除linq以外的场合中原则上不应使用var,它毕竟违背强类型语言的本质。在这个问题上有过纠结,曾经看到实施ASP.NET MVC的团队为了更方便的分离view与control开发而在页面层大量使用var,事实虽然没有完全否定这种做法(项目最终实施的还算可以),但我依然坚持观念,看到本书作者与我一样的想法还是挺安慰的,现在坚定认为即使是编译时的类型推断依然违背强类型语言原则,语言的好坏更多地是看在人的眼里好不好而不是在机器的眼里好不好(执行速度相对比较低效的python获得如此成功不是没有道理),使用此类技术应该仅仅存在于领域语言(DSL,如linq),不适合大范围混搭使用。
4. 非泛型集合类因为没有实现IEnumerable<T>所以没有被扩展linq查询,但却扩展给了一个OffType<T>方法,可以直观地转换为泛型集合类,这也是之前没有料到的,在重构旧系统的时候这个方法应该很有用武之地。
5. linq核心方法Func最多支持16个独立数据源,虽然几乎不可能遇到此瓶颈(之前以为会以二叉树的形式支持无限地数据源)。
耐心看书学习的过程很满足,很充实。如果有机会,很想对以前的自己多劝慰几句:“戒躁,戒躁 …”
2011年1月28日
RequireJS
与LABjs不同,RequireJS不是依赖js文件来分离模块,而是根据配置声明来分离模块,使用一个jre环境下的命令行处理产品部署阶段的工作。好处很明显,编码归编码,部署归部署,在编码阶段中你想怎么构建自己的文件结构就怎么构建,短短地一行代码放置在一个文件中也无妨。
RequireJS最大的问题可能就是only-jquery,虽然有合并包提供下载(能够减少大量代码),但依然显得RequireJS非常臃肿,与LABjs形成鲜明反差。
后记:
关于RequireJS的发展,可以参考玉伯的这篇博客《CommonJS 的模块系统,AMD 和 Wrappings, 以及 RequireJS》(原文地址已丢失,好不靠谱的家伙啊-_-!),不过技术绝对靠谱,非常期待seajs的成长,一直在跟进它的邮件列表,能够有一个适合国内恶劣网络环境的module加载方案是多么让人舒心的事情~~