现已完成第二个版本,修正了这个版本的几个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 |