.NET 有的没的

转眼间发现快一个月没有更新BLOG了, 终于明白了为什么有那么多人整天说忙, 现在轮到自己了, 是不是瞎忙还不清楚, 但是是真忙.

总结一下这个月的新发现:

WCF 数据契约不是专指 DataContract 而言的吗?

Allan 的文章里看到:

WCF 在 .NET3.5sp1 中, 实体类即使不指定 DataContract 特性也能够被序列化. 具体规则是:

  • 不指定特性, 序列化公有属性.
  • 指定 Serializable 特性, 序列化所有属性.
  • 指定 DataContract 特性, 仅序列化注明 DataMember 的属性.

之前确实不知道, 还有这么一说, 试了试也确实如此. 不过对我来说 DataMember 的 Order 属性同样重要, 所以还是坚持原来的做法好了.

MySQL 要怎么对付 Guid?

这个问题一直困扰着我, 在 MySQL.NET 连接器 5.2 版的更新中有这样一句:

BINARY(16) columns are now treated as Guid objects

嗯, 我该如何理解这句话呢? 暂且当做是官方的建议好了. 不过接下来实在是忍不住要抱怨一下.

当列类型是 BINARY(16) 的时候, 我该如何把一个 Guid 存入数据库呢?

显然拼接 SQL 语句是不行的. 况且对于我这样的一个完美主义者来说也是不可能容忍的.

那么参数化插入会怎样? 答案是报错: 数据太长. 看来连接器是把 Guid 当成字符串装入参数了, 那的确是太长了 (36比16). 看来我还得自己手动转化成二进制才行 (ToByteArray), OK~ 这次算是插入成功了. 不过接下来在查询浏览器里看到的结果就… (…æýO.-áG©÷).

等等, MySQL 不是有个 UUID() 函数么?, 难道它不能和 Guid 统一起来么? 答案是”不能!”. UUID 的生成原理与 Guid 几乎相同, 但结果却不一样, UUID 本质上是个字符串, 而 Guid 却是 .NET 的一个类型. 倘若我们使用 VARCHAR(36) 来做主键, 不仅仅是空间上的浪费, 索引的性能, 而且还会带来存取双向转换的麻烦.

反观参考手册中的那句话 (treated as Guid), 大概意思是说一个 BINARY(16) 列会被当成 Guid 读取, 但你不能直接把 Guid 存储进去. 唉~

MySQL 名称引号陷阱.

用过 WorkBench 的人肯定知道, 数据库名和表名会用”点号”括起 ( Database.Table ), 也就是数字 1 前面那个键.

我因此也想当然的认为这是官方的”建议”, 这样括起的部分应该不会被语义解析, 而是当成名字来使用, 所以我在存储过程中写下了灰色的一段:

1
2
3
4
5
CREATE PROCEDURE `TEST`.`User_Delete` (id BINARY(16))
BEGIN
  DELETE FROM `User` WHERE `ID`=id;
  SELECT ROW_COUNT();
END

我本以为这样名称会统一些, 虽然我知道 MySQL 是不区分大小写的, 不过括起来的 ID 自然会代表列名, 而 id 自然是传递过来的参数. 结果 MySQL 却不这样认为, 那条 WHERE 语句被解释成了 id=id (又或者 ID=ID)

User 表就这样被清空了… (还好是测试!)

F# 项目组近来在忙什么?

已经很久没有关于 F# 的任何新闻了, 很久是多久? 可能两个月左右吧, 是有些心急, 只不过感觉有些奇怪, Don 的博客没了更新, cs.hubfs.net 也变得冷冷清清, 连 MailList 都不如以前热闹.

昨天再一次碰到智能感知失效的问题, 这次精准定位到了 System.Xml.Linq 上面, 只要打开这个命名空间就会导致某些类型的智能感知显示不出来. 成员列表只有一个 <None>, 显示的信息是:

>
a reference to the type ‘System.Xml.Linq.XNode’ supposedly in assembly mscorlib was found, but the type could not be found in that assembly.

我决定把这个问题反映到 hubfs 上面去, 证实这的确是一个 BUG, 只不过早就有人提交过了, 让我感兴趣的是这句:

>
It is already known and fixed in the latest internal version.

嗯, 看来项目组没有偷懒, 只是可能版本处在一个大的跨度区间上面, 没办法单独发布吧.

DLR 为什么会和 Silverlight 走的这么近?

Silverlight 动态语言 SDK 已经出现有一段时间了, 另一个动态语言运行时也在跃跃欲试, 再看看这个用 Silverlight 实现的 DLR 命名行 吧. 他们到底想要干什么? 动态语言就一定要和动画联系在一起么? 或者这样才符合 DLR 时髦的外型?

当然对于 Python 我知之甚少, Ruby 一直没太大的兴趣, 至于 JScript 不是已经死了么? 难道是死而不僵?

抛开这些个人的喜好, 推荐看一看 rednaxelafx 的一套文章, 了解一下 DLR 的前世今生, 从某种意义上说, 可以认为 IronPython 对于 LINQ 意义真是蛮大的, 这种作用就好像 F# 之于 Lambda, 如果继续说下去又会被当成谬论了, 那么, 好吧, .NET是一家.