高效的实体类操作类

现已完成第二个版本，修正了这个版本的几个BUG，并进一步提高了性能。有需要的请留言并关注，因CSDN的下载中心做的太死板了，一旦传上去的东西，就不让修改，所以不敢随意上传，直到完全没问题了才行。

实体类使用的越来越多了，很多框架也层出不穷，例如EF，但是我没学过，我更倾向于自己设计框架。

看到过一些人自己设计的实体类框架，效率惨目忍睹，因此，我设计之初就非常注重效率，如果效率不高，不如直接用现有的ORM框架呢。

无意中发现了一个叫Dapper的实体类操作类，其主页在：http://code.google.com/p/dapper-dot-net/，通过研究，发现其思路很不错，非常适合设计高效的ORM框架。但是我从来不满足现有的框架，总觉得不够强大，经研究后，对其做了一些改动，使其更加强大，现在放出改动内容和修改后的文件。

http://download.csdn.net/detail/qldsrx/4219682

修改一：添加了数据类型转换。例如，当定义的实体类某个属性是bool类型的，而数据库不支持bool类型(如Oracle数据库)，那么我们一般认为0为false，非0为true，映射到实体类就需要转换，原来的操作类就修改。

修改二：一个小BUG，原操作类对空映射的一个处理上有点小问题，被我细看后发现，已修正。

修改三：添加了动态实体类的控件绑定支持。原操作类已支持返回动态实体，无需给定一个具体的类型，而返回一个dynamic类型的实体即可，其属性由查询动态产生，但是产生的这个动态实体类却无法直接给控件绑定并显示，因为无法通过反射得到内部属性结构，现做改良，可以直接绑定到类似DataGridView的控件上面。

基于这个高效的实体类操作类，我们可以设计出一个属于自己的，非常高效的ORM框架，而不用使用各种无法自定义的第三方框架，受限于别人了。不过这个操作类只能在直接的数据库访问时使用，其输入输出参数不支持序列化，因此WCF通讯中无法直接使用，我已在进行WCF通讯的改良，让其可以用在WCF通讯中，尚未完成。

 

有不少人看到不喜欢点击链接，或者看到Dapper主页是英文的就看不下去了，特此截取一段测试内容，从图中可以看出，Dapper的速度仅次于手写代码(Hand coded），可谓效率最高

Performance of SELECT mapping over 500 iterations - POCO serialization

Method	Duration	Remarks
Hand coded (using a SqlDataReader)	47ms
Dapper ExecuteMapperQuery<Post>	49ms
ServiceStack.OrmLite (QueryById)	50ms
PetaPoco	52ms	Can be faster
BLToolkit	80ms
SubSonic CodingHorror	107ms
NHibernate SQL	104ms
Linq 2 SQL ExecuteQuery	181ms
Entity framework ExecuteStoreQuery	631ms