编写人生

请先参考《相信自己，我能》 关于读取性能的测试

今天对插入的性能做了比较，和我预期的一样，Torridity的性能和其他的产品基本打平手，而Entity Framework一样是糟糕的成绩。
为什么认为会打个平手呢？因为插入1万比记录，意味这连续发送1万次SQL，在没有提别糟糕的程序下，基本上SQL语句的执行花去了几乎大部分的时间，程序本身的优化所得到的提升几乎微乎其微。
下面是测试结果：

再次失望ADO Entity Framwork的性能，太糟糕了

关于元数据结构
自动创建的代码包含一个派生自ObjectContext的对象，他有点像一个Workspace，主要包含连接、元数据和状态管理等；

ObjectContext包含一个MetadataWorkspace属性，记录了所有的元数据信息，有几种类型：
C  Space: 很全，包括数据类型（例如Byte）、函数(例如Max）、实体类型（例如Order）；
CS Space：null?没有吗
OC Space：纯数据类型，一般13个；
S  Space：包括数据类型和实体类型。
你可以像下面这样的代码获取元数据
EntityType c2 = c.MetadataWorkspace.GetItem<EntityType>("DcmsCore2_TestModel.Customer", System.Data.Metadata.Edm.DataSpace.CSpace);

枚举出一个元数据对象，怎么知道是描述什么的呢？BuildtInTypeKind属性可以告诉你，常见的有：
PrimitiveType    : 原生数据类型，例如描述string的
EntityType       ：实体类型，一般是ClrEntityType的实例，例如描述order
MetadataProperty : 属性，例如描述Order的属性OrderId；
Facet            ：特性，用来描述是否允许null，或缺省值之类的东西，有点像CLR里面的Attribute

今天，是个值得纪念的日子，因为我编写的ORM（名为Torridity）工具经过性能测试，其读取性能全面压倒DataSet、LinQ和DataEntity Framework。

从截图中你可以看出，我们比DataSet快2倍，比LinQ快4倍，比Entity Framework beta 3快14倍。

测试采用读取1万笔记录，而且为公正起见，所有的计时开始前，都预先读取一笔其他的记录，保证不是连接缓冲池造成的误差。而且测试代码保证都是各自工具最佳的读取方式。

你可以下载附件中的测试程序，但非常的遗憾，Torridity属于公司的财产，所以我不能包含任何关于此部分的代码。要测试程序请：

  - 使用Visual Studio 2008打开项目；

  - 下载Entity Framework beata 3；

我将在随后的时间测试保存、插入和删除功能的性能。

LinQVsTorridity.rar 

微型电动轿车(发明畅想)
智能电视的设想（发明畅想）
压缩空气动力自行车

我们大家去自助取款机提款时经常有这样的经验，一台取款机已经没有钱了，你插入卡输入密码，一看没有钱，白忙了，只好在旁边的取款机排队，可是同样的事情不断的在后面发生，所有人都想试试看这台机器然后和你一样失望的走到这边继续排队。
所以为什么不在取款机的上方设计一个“钱箱没有钱了”的提示灯呢？最好不断的闪烁的那种。

        [OnDeserialized()]
        private void OnDeserialized(StreamingContext context) {
            this.OnDeserialization(null);
        }

private DependencyPropertyData _data;

对象将被彻底重新构造，并且在反序列化期间调用方法可能会产生不良的副作用，因为被调用的方法可能引用在进行此调用时尚未被反序列化的对象引用。如果反序列化的类实现 IDeserializationCallback，则在整个对象图已被反序列化后将自动调用 OnDeserialization 方法。此时，所有引用的子对象均已被完全还原。哈希表就是在不使用事件侦听器的情况下很难反序列化的类的典型示例。在反序列化期间检索键/值对十分容易，但将这些对象添加回哈希表可能会造成一些问题，因为不能保证从哈希表派生的类已被反序列化。因此，不建议在此阶段对哈希表调用方法。

今天看见一篇文章【C#食谱】【面食】菜单1： 何时何地使用泛型 ，总结的很好，我也总结一下，不过是反过来的：何时何地不能使用泛型。
注：以下未特别注明的话，均表示不能对外展现泛型，内部仍然可以使用泛型。
1、控件上，在控件上public一个泛型的属性，意味着窗体设计器无法打开。同样的，在重用的组件上也意味着不能打开设计器 了；
2、WebService上，据我目前所知，目前的WebService规范是不支持泛型的，不管是对外接口，还是返回/传入的数据类型；
3、COM的互操作，COM是不支持泛型的。

解决方案：
在以上的应用中，我们又如何避免泛型带来的麻烦呢？一般你可以：
1、包装泛型类，使其特例化，不再具有泛型的特征。例如：
public sealed class DependencyPropertyCollection : ReadonlyNamedCollection<DependencyProperty>
2、 定义非泛型的接口，将泛型的返回值或参数使用object方式访问，适合COM操作。

欢迎大家补充。
补充：竟然有人说这是垃圾文章，哎，算了，不要丢人了，不要放在首页了。