RELEASE

传说，人老了总会怀念过去。但是，我似乎还没老丫？

前段时间，晚上做梦，梦到了小学同学，似乎是吵架的事。对方是女生，突然发现，我小时候那么混蛋。当时，把人家弄哭了，而她哭，并不是因为和我吵架，而似乎是一种伤心，失望的感觉。之后，还给我一封算是信的纸条吧，现在回想起来，真的惭愧。

就在昨天，初中兼高中的电脑老师打电话给我，我一下子就猜出来是谁了。应该算我计算机方面的启蒙老师吧。刚上大学时，还有少许联系，之后就断了。其实，之前好几次想找找以前的几位好老师，可惜，学校搬了或是老学校里的老师班子都换了。改天去看看她“老人家”:)，还有高3时的班主任，小学的班主任，以及小学3年级的数学老师，都是好老师呀。

小学里，还叫得出名字2个人貌似都结婚了。想想真是可怕，之前还在家附近的小花园跑来跑去，互相串门，转眼，几乎成了2个世界的人了。

我又不知所云了，不知我所云者直接忽略本文……呵。算是纪念一下才活了1/4个世纪的自己吧。

在做ORM=>UI的框架时，对于查询，我没有直接绑定Linq返回的结果集，而是将他们转换为DataTable再绑到DataGridView上，这么做的原因有4：1、Linq结果集是单向访问的，无法让DataGrid自动对其排序。2、外键的处理，Linq直接绑到DataGrid上，外键无法显示，也可以在查询时，使用匿名类的方式创建一个新类型的结果集包含外键信息，但动态Linq的实现颇为麻烦。3、绑定后，不好确定用户选择的对象，特别是如情况2所述的做法。4、本框架的其他部分数据源主要采用DataTable形式，可能会存在交互，故此处还是采用DataTable。

于是，主要的问题就在于IQuayable到DataTable的转换了。实现不是问题，效率却是。由于是一套框架性中间组件，对于最终被应用的Linq O/R mapping类型是完全不可能知道的，所以采用反射的方式。

我的测试数据是9000条数据，5个外键，2个明细档，共20个字段。最初，没考虑性能时的实现，包括查询到显示完毕，耗时26秒。完全不可接受！

于是：做了如下调整：

多线程处理+缓存反射对象如PropertyInfo+改变dr[columnname]=xxx的赋值方式，采用LoadDataRow/Rows.Add(object[])方式，时间缩短为8.5-9.5秒

显然还是不可接受的，最初怀疑对DataTable的填充有更快的方法，通过反编译.NET Framework代码，发现MS填充DT的方式也是LoadDataRow，于是，这个可能排除。

那么，就是反射了……传说中能比直接访问效率差1000倍的反射……于是，我采用动态编译一个类，采用强类型的方式读取数据，然后写入DataTable，时间缩短为7.4秒

只提高了这么点点？！才10%？不是号称1000倍么……可见，问题不在这里。

怀疑是封箱操作占的资源，写了个测试程序，分别测试几种操作的差别和效率，结果如下：
直接调用类属性100000次，共耗费：00:00:00.0020000
直接调用类属性100000次，共耗费：00:00:00.0050000 (做封箱操作)
直接调用类属性100000次，共耗费：00:00:00.0060000 (通过外部函数)
反射调用类属性100000次，共耗费：00:00:00.7880000 （缓存反射对象）
直接调用类属性100000次，共耗费：00:00:00.0020000
直接调用类属性100000次，共耗费：00:00:00.0050000 (做封箱操作)
直接调用类属性100000次，共耗费：00:00:00.0060000 (通过外部函数)
反射调用类属性100000次，共耗费：00:00:00.8060000 （缓存反射对象）

速度基本上是稳定的，封箱操作要比强类型慢2.5倍，而通过外部函数访问外加封箱操作则慢3倍，而反射……则是400倍……（看来1000倍的说法是夸张了，但这里缓存了反射对象，否则的话也许更慢）。

其实还有人提出了通过委托来解决反射的效率问题，不过这仅仅适用于方法调用和对一个对象调用多次的情况。

那么问题到底在哪里……ADO.NET填充一个dt，9000行数据最多也就1秒了吧……我就算多了层linq，外加外键的延时加载，2-3秒应该够了吧。外加别的因素，如子线程可能优先级没主线成高- -？我在填充时还提供了Progress的委托事件（界面上进度条显示），再加1秒……4秒应该能搞定了吧？

反复尝试，最终还是停留在7.4秒……无奈下，加了个分页功能，好歹维持在一页1-2秒吧……

不过，最终还是把目光放在了延迟加载的问题上，经过sql的跟踪，发现每笔记录都会去加在明细档，恍然大悟，我添加了一个额外的自定义属性，剩余金额=总金额-明细中已付金额之和。原来是这里读的明细档。作了个试验，去掉了这个属性，作了一次查询，4秒……很好，在可接受范围内了。看来真是这玩艺导致的问题。

当然，这是最终项目的设计逻辑上的问题，而非框架层的问题，至少……我可以说，Linq结果集->DataTable的转换，我这已经没什么优化方案了。即便也许转为Dt并非最优解。但基于之前4个原因，这样的转换还是有必要的。

最终，应用层上，我的解决办法是，添加一个剩余金额的字段，在保存记录时，计算该值并一起保存。不过由于这个应用层的失误，导致花了近2天来处理效率问题，还都是无用功，真有些郁闷。但对于各种方式的效率差，也有了一定认识，还是值得的。

注：由于基于Linq，对于性能要求很高的项目或模块不一定适合本方案。对于复杂查询要求较高的情况，本方案也不一定适用。本方案主要针对中小型项目，普通信息维护管理系统。

从数据库，到数据访问层，再到界面。一层层的搭，大量的重复劳动。耐心再好的人也会厌倦吧？

比如一个叫做Employee表，EmpID,Name,OnBoardDate,Birthday,Manager,Title等字段，那么，最简单的，要做 新增/修改/删除/查询 4个功能，不一定要ORM，也不一定要数据访问层独立出来，但最麻烦的应该就是画界面了，当然，还有输入数据合法性检查等等。设想一下，表结构设计+表创建，30分钟；增删改查 功能函数，30+10+20+60=120分钟，界面算上调整和格式检查得要1天吧。以上时间算上了基本的测试时间。按平均速度算，应该算是不宽裕了（不排除0.5天或者2天才能搞定的）。

现在，微软随C# 3.0和Visual Stuido 2008一同发布了Linq，其中的Linq2Sql是一套轻量级的Linq解决方案，在数据库设计完成后，即可通过拖拽的方式得到一套ORM类。同时，还包含延时加载机制，就数据查询来说，是通过Reader对象，所以效率来说不会比DataTable/DataSet低。其他特点不再多说，网上满地的介绍。我看中的，在于对于数据库设计信息，完全的包含到了类中。这就为根据这些信息，自动生成界面成为可能。

看一下例子，还是上面描述的员工表：

在Linq2Sql的设计器中，加上 经理->EmpID 的关联关系。ORM这层就算完成了，之后，如果作为基础数据，可以使用已经封装好了frmMaintenance类。如下：

frmMaintenance f = new frmMaintenance("Empolyee", null, typeof(Employee), true, true, null, null, null, null, null, null, null);

为null的参数中包括格式验证/权限验证可用的托管，额外的查询条件限制等。运行效果如图：

当然，字段也许还需要修饰一下，为了看出效果，将字段显示为中文，通过提供的配置工具，可以为ORM对象设置默认的字段信息，

还为外键/明细档等提供了额外的属性甚至可以设定外键显示的字段以及配置信息的嵌套功能。最终可以把这些配置序列化保存，作为默认配置。当然也可以为某些控件做个性化设置。

如果要做查询的，可以直接拖一个封装好的Query控件：

以及3句代码执行以下绑定设置：

querier1.DataContext = new DataClasses1DataContext();
querier1.MappingTable = typeof(Employee);
querier1.DataBind();

看一下执行效果：

可以根据各个字段填入条件，做符合查询。于是，最简单的增删改查，在数据库设计完毕后，仅需要5分钟和4句代码就可以搞定了。当然，还包括一些复杂功能，如数据权限处理，在查询条件上再附加条件，等等，或者希望在更复杂的界面中，集成编辑功能，等，都留有对应的控件和接口。

下面是一个，使用本框架搭出的一个小程序的2个界面：

本来7月底才发行的Stargate系列最新的电影，已经可以下载到了，感谢全球的盗版工作者。

国内fans，字幕组等翻译为《星际之门：连续体/时空连续 》等，总感觉非常别扭，但也难找出合适的中文字与，暂且还是叫英文原名吧。

片子，总的来说不错，情节贯穿本系列的初头，1939-2008。但作为一部电影，感觉情节不够饱满。或许是数个月来过于期待，没有达到理想的高度。空战场面不及S7末尾，整体情节更类似于S8中修改时间线的两集，缺乏新意。

整体感觉，情节实在有些赶，不少内容都可以更好扩充一下。但片子还是喜欢的，美国海军和空军貌似都给这片子开了绿灯，潜艇北极上浮，以及F15的场景。整个片子看完心里又觉得空空的，不知道下一部星门电影什么时候出。美国人好好的买Continuum的DVD啊~~别让电影系列也被砍了。

开始期待Stargate Atlantis S05E02~~

问题描述：通过openrowset跨库访问其他数据库，发现select出的中文数据就是乱码，更别说插入当前库中了。如：

select * from openrowset('SQLOLEDB','server';'userid';'password',DBNAME.dbo.Table)

解决思路：有乱码的字段显然是varchar类型，sql 2000中，特别容易导致双字节字符乱码。由于问题出在跨库查询（2库默认排序规则相同），因此只要在源库输出数据前将字段转为nvarchar即可。于是改为：

select * from openrowset('SQLOLEDB','server';'userid';'password','select cast(F1 as nvarchar) as F1 from DBNAME.dbo.Table')

乱码问题解决。

两年来没好好运动了~~~昨天打了近2小时羽毛球......今天........站着坐不下,坐着起不来,走起来还一拐拐的.....

大学毕业都近2年了，本完全无视曾经经历的那段时候了，也完全无视中国教育的种种弊端了，不过今天看到一个关于“三个金人”高考小作文练习题，实在还是想说两句。

貌似这故事也很古老了，我那时候应该就有，只是我运气好，那时没见过这题。故事是这样的：

     曾经有个小国到中国来，进贡了三个一模一样的金人，金碧辉煌，把皇帝高兴坏了。可是这小国不厚道，同时出一道题目：这三个金人哪个最有价值？
　　皇帝想了许多的办法，请来珠宝匠检查，称重量，看做工，都是一模一样的。怎么办？使者还等着回去汇报呢。泱泱大国，不会连这个小事都不懂吧？
　　最后，有一位退位的老大臣说他有办法。
　　皇帝将使者请到大殿，老臣胸有成足地拿着三根稻草，插入第一个金人的耳朵里，这稻草从另一边耳朵出来了。第二个金人的稻草从嘴巴里直接掉出来，而第三个金人，稻草进去后掉进了肚子，什么响动也没有。老臣说：第三个金人最有价值！使者默默无语，答案正确。

说实话，这故事，看了之后实在不知所云，或许是我天资愚笨吧？！google一下，原来是说“最有价值的人，不一定是最能说的人的人。老天给我们两只耳朵一个嘴巴，本来就是让我们多听少说的。善于倾听，才是成熟的人最基本的素质。”

说实话，真不知道是我愚钝还是编故事的自作聪明，故事中用词不当，还有错别字，更主要的是逻辑混乱。真的，没知识就别学伊索写寓言，就被学圣经写故事。更重要的是，别当老师误人子弟，特别是浪费要参加高考的同学们的时间来硬凑你的所谓论点。

1：“三个一模一样的金人”，那么“珠宝匠检查，称重量，看做工”就愣是没发现第一个金人2个耳朵的洞是通的？
2：“金碧辉煌”的小金人？金碧辉煌是形容建筑物装饰的，不是用来形容小物件的。
3：“老臣胸有成足地拿着三根稻草”原来不是胸有成竹啊？

就是这种为出题而编的故事，堂而皇之的反复用来被高三学生们练习写作，google一下，居然被大量网站当成哲学故事。呜呼，高中的语文老师们，有点判断能力好不好，教学也要取精华，去糟粕；莫为出题而出题。呜呼，网站的编辑们，有点分辨能力，别不动脑子的复制粘贴，互联网也不需要那么多的重复性垃圾。

当然，高考在即，老师们希望学生可以多联系的心情可以理解，但请将真正有价值的题目给学生们练习。别让学生由于看不懂糟粕而丧失信心。

似乎，最近越来越FQ了，哎……应该老了呀:S

平日，无聊时，常开打mop,tianya解闷看其口水仗，却从未发言。对于所谓“精英/JY”和“愤青/FQ”，有时也会自评一下，而把自己归为前者。然，今四川地震，再看论坛发现，原来我又变为FQ阵营的了。于是自嘲，我算是不左不右的吧？

7.8级的地震，大家都很关心，讨论也是异常激烈，但一股风气就是把责任往ZF头上推？我真不禁发问，何故？曾被父亲评论为挺反动的我，实在不认为本次地震，各个环节，ZF有什么严重失职与需要被强烈诟病的。

一条条说：

刚地震时，就大量的“那么大地震，政府为什么一点预警也没有？”
君可知，全球至今没有任何一个国家可以做出权威官方的地震预报？全球相关科学研究都表明，目前根本无法做出准确的地震预报。

然而，接下去，更戏剧化，一些小丑跳出来，“既然预测不了地震，国家养他们干什么？不如养蟾蜍，养狗。”即所谓专家不如狗的言论。
当今，“专家”这词在网络上已偏向贬义，各个领域，不断有所谓专家发表可笑言论，致使，大量网民对于专家的权威性产生质疑，这可以理解，我也是。但本次地震，责怪相关专家没有发出预报和预警是完全没有道理的。甚至，说看动物行为就能知道要地震了这种可笑言论。我倒是要反问这些事后诸葛亮们：若5月12日早上，你出门看到满街蛤蟆，若5月12日早上，你家的狗对你吠鸣；你们会意识到，今天要地震？！；若去年的今天，有人告诉你们，2008年5月12日，四川要有一次不亚于唐山的大地震。你会相信？你会防范？你不会骂他神经病，以为他是轮子功？

貌似这2轮的无理取闹还没结束（开始对于没有预警的疑问可以理解，表现了广大国人急切的心情），又有人搬出了几年前某硕士论文，预测08年川贵地区会有大地震。这似乎为“地震”可以预测提供了口实。
但，时间进度为一整年，地理位置为比四川全省更广大区域，试问，这样的“预报”有何意义？更不用说，其计算方法是否科学。

地震预测告一段落，又开始了对ZF反映速度缓慢的指责。
对于这类指责，我不得不像一个FQ一样来怀疑这撮人拿着谁的工资在上网，这次ZF的反映速度，可以说是非常之快了，震后多久就启动应急预案？多久温家宝到达灾区？多久就调集救援？多久就开始财政拨款？请google,badu一下。

随着电视里关于学校倒塌的新闻，又是众多关于“为什么倒的都是学校，政府机关都没事？”的论调。
那么北川民政局大楼倒塌，23名工作人员16死又算什么？

接着，救援不力的声音又出来了。
山区，暴雨，公路全断。不知道救援得力的情况会怎么处理。但当救援部队冒着余震危险，徒步设法进入灾区的时候，这么叫嚣的人们在干什么？

费口舌之力，不如实际行动，捐款捐物吧？！可接下来的，是对被捐款项是否能到灾民手上而不是贪官口袋里的疑问声。
不可否认，这是个问题，但这不是拒绝捐款的理由，“我不想捐”，“本人经济拮据”——这些是理由，但怕被贪污恐怕只是借口。你可以减少中间环节，直接向四川捐款或是捐急需物资。如果真有一份心，愿意为灾区出一分力的话。

暂时写这些，偶尔FQ一次吧。不可否认，本次救灾ZF的行动是非常值得肯定的。

整个过程持续了3周~~~特别感谢Milly和Shirley~~~有机会请你们吃饭~~~！

下个月要还买机器的钱了~~~

原装配置：酷睿2 L7500 1.6G，2G单根内存，80G SATA硬盘，1G迅盘，蓝牙，Intel 802.11 abg无线网卡，1400*1050 12寸SXGA+光视角LCD，指纹，8芯电池

基本感受：整体上很不错，键盘感觉比T4x稍硬，有些不足的地方为：8芯电池只能支持3-4小时比较失望，显卡Vista得分仅2.7 偏低。屏幕上有一层“雾”一样的感觉。

整个过程如下：

再次感谢Milly和Shirley~~~~

附购买流程和心得

一：购买之前
有想法从联想美国网站购机是在2年前，那时候看到联想网站上的价格比国内便宜不少，比较心动，但毕竟那时候差价不是很高，且运费/海关等不确定因素太多，就没事实行。不过确实一直在关注这方面。去年，看到联想网站上的价格已经不错（X60 Tablet 那时候按我的配置下来是1700$）而卖场里问的最低配X60 Tablet行货也要18000RMB。那时候看到lenovo网站上的信用卡政策是：仅支持美国本土信用卡，国际卡仅支持美国运通卡（American Express）。于是，开始考虑怎么申请AE卡，AE原发卡是没希望了，不够资格，只能选 工行运通 和 中信运通。最后选了工行的，不过额度才10000RMB/1000USD，不是很够，本打算提额之后下单买。
但到了今年（2008）3月份，在51nb上转悠的时候看到了一个cpp的帖子，一下子15% OFF~立马心动……听说还有累加优惠可用，但找来的都没用，暂时放弃。然而这时候我的T43显卡坏了~~~虽然能用，但常出问题（确认是硬件问题），开始下决心从cpp下单。
二：购买
3月中旬的时候，看到了cpp上X系列累加10% OFF的优惠，再也忍不住，决定下单，我的配置配下来1314.53$。我的运通卡显然额度不够，由于之前看到有XD使用建行VISA支付成功，外加现在网站已经没有以前那段非常绝对的只接受本土信用卡和运通卡的说明。于是决定用自己的建行VISA试试。
进入http://www.lenovo.com/cpp/，开始配我的机器，选上蓝牙，迅盘，8芯电池。checkout之前输入了eCoupons，最后checkout，这时候需要注册一个帐号或者用guest checkout，其实可以考虑用后者，因为不注册可以quote当前订单，1个月内有效，如果涨价了或电子优惠券过期了还可以用这个价格购买~。还有，务必考虑你美国联系人所在地的消费税。我朋友在华盛顿州，消费税达到了9% ！我的eCoupons完全就用来抵税了……
注意：Shipping/Billing Address极度建议填写一样的，根据我的理解，只有当他们不同时，联想才会去check你的信用卡地址，以确定你的身份。目前看来也确实如此。理论上，信用卡预授权成功，应该就不太会cancel你的订单了。之后你的订单将保持in process状态，直到装配完成。注意，只有当工厂装配完成，你的订单状态才会变成shipped，而不是变成shipped之后才装配。shipped之后的几个小时，你就可以在shipped边上找到tracking link来跟踪包裹了。我3/17下单，9天后shipped，4天后送达美国收件人处（西雅图）。
三：购买之后
寄回来，我选的是USPS，毕竟是海关抽查，有逃税的可能。不过，我感觉，即便交上1000块关税，也还是便宜不少，所以报着能逃最好，逃不过就交的想法。UPSP的价格很便宜，Express Mail寄7磅重货物才55.55$（含100$保险），另外买了900$保险(3.45$)。如果是T系列再重0.6KG，运费大约70$总共。
我的包裹用了大约4天到手，西雅图-上海。美国USPS网站上状态更新不是实时的，EMS的状态之后包裹到ＥＭＳ控制之下时才实时更新。运气不错，没进海关，省了１０００。
我的包裹保价999$，内容写的是PDA，用的还是联想的盒子，撕掉了标签。
四：感受
总的来说，全程我自己配机，跟踪本本状态，以及最终价格都感觉比以前买水货好。主要缺点是流程较长。如果感觉这2-3周等起来是种煎熬的话，可以考虑买水货。另外，这样购买可以刷卡，算好时间，可以获得超过60天的免息期（预授权之后是不扣款的，机器发货后才扣款，如果可以算好发货时间为账单日之后1，2天，那么下单-发货大约5-10天或更长，加上银行50-56天免息期，可以达到60天以上）而且美元还在天天跌~晚购汇更合算。

附：奇特的UPS发货记录：

城保/镇保的主要区别:

城保：个人/公司都负担一部分,最低基数为去年上海市平均最低工资，最高基数为最低基数的6倍，若你的个人工资在这区间内，则取个人工资为基数（实际应为去年平均工资）。其中个人负担18%，公司负担38%左右。 （其中包括公积金）

镇保：个人不负担，公司负担统一为去年上海市平均最低工资的60%为基数的24%。不包括公积金。公积金可参考城保基数（个人/公司分别负担7%）

若镇保的养老转到城保，1年镇保=0.6-0.72年城保

若镇保的医疗转到城保，账户余额不会转到城保账户中。（因为镇保个人不负担，公司交的少，所以医保账户中是没钱的）

然而：

如果当前是交城保，中间找了交镇保的新工作，将来再转回城保，那么：

城转镇，医保账户余额转入镇保账户，将来，再从镇保转回城保，那么 医保余额就冻结在镇保账户里了，城保账户里余额=0。这些冻结的钱，只有2种情况能支取：

1：退休

2：城保的医保账户余额=0，且你去医保医院看病，那么可以凭借发票去医保局报销。

3：再交镇保……

什么公司会缴纳镇保：

1：注册在郊区的或浦东新区的

2：要求你和注册在郊区或浦东的人力资源公司签劳动合同的

交镇保而导致的损失：

1：养老金的损失，这是众所周知的了，退休后，退休工资基数为当年平均工资的60%。而城保的退休工资基数为当年退休工资。若要转为城保，那么，工作年限=镇保缴纳年数*60%左右，也就是说，2年等于1年！

2：医保账户，如上所述，城保-〉镇保-〉城保这样的转换将导致以前的城保里的医保资金被冻结在镇保里。

总之，同学们，同志们：小心啊!

终于RTM了~~~~不容易.....上次装的其实几乎也是RTM了, 2007/10/22号build的~~~

框的地方，最后.7是零售版的RTM，图上的.8是自带序列号的内部发布版，MSDN版是啥版本号就不知道了。今天车上，看到Intel的家伙也用2008 RTM了……K，也太快了，Intel和MS的关系原来如此紧密……

最喜欢的一点，同时支持.NET Framework 2.0/3.0/3.5，不像以前，必须要装2套VS IDE才行。

如果RTM可以捆绑Silverlight和WM6 SDK就好了，可以省不少麻烦~~~VS2008工具条load很慢的问题从Beta1就开始存在，Beta2 branch最严重，RTM都没根治……