飞乐ED330搭配什么声卡最好~ 3000以里的卡_声卡吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：52,413贴子：
飞乐ED330搭配什么声卡最好~ 3000以里的卡收藏
专业声卡,苏宁易购,品牌网购商城,品牌专属网络销售,支持货到付款,省钱又放心!专业声卡,苏宁易购正品低价,支持货到付款!7天无理由退换货,100个城市半日达!
看你的用途。录音还是k歌呢？
用来娱乐还是录音哪？
马头啦 罗兰啦 雅马哈啦都可以
唱歌就6nano
录干声就雅马哈
这个主要看你的用途哦
马头吧 K歌 录音全OK
MOTU马头不错，我可以用YAMAHA UR44
9632 外置就马头
但是WIN系统下驱动不稳定
登录百度帐号用事实说话，成熟的ORM性能不是瓶颈，灵活性不是问题：EF5.0、PDF.NET5.0、Dapper原理分析与测试手记 - 深蓝医生 - 博客园
随笔 - 216, 文章 - 1, 评论 - 2426, 引用 - 0
[本文篇幅较长，可以通过目录查看您感兴趣的内容，或者下载格式良好的文件查看]&
&一、ORM的"三国志"
1，PDF.NET诞生历程
　　记得我很早以前ｉ（大概05年以前），刚听到ORM这个词的时候，就听到有人在说ORM性能不高，要求性能的地方都是直接SQL的，后来谈论ORM的人越来越多的时候，我也去关注了下，偶然间发现，尼玛，一个文章表的实体类，居然查询的时候把Content（内容）字段也查询出来了，这要是我查询个文章列表，这些内容字段不仅多余，而且严重影响性能，为啥不能只查询我需要的字段到ORM？自此对ORM没有好感，潜心研究SQL去了，将SQL封装到一个XML文件程序再来调用，还可以在运行时修改，别提多爽了，ORM，一边去吧：）
　　到了06年，随着这种写SQL的方式，我发现一个项目里面CRUD的SQL实在是太多了，特别是分页，也得手写SQL去处理，为了高效率，分页还要3种方式，第一页直接用Top，最后一页也用Top倒序处理，中间就得使用双OrderBy处理了。这些SQL写多了越写越烦，于是再度去围观ORM，发现它的确大大减轻了我写SQL的负担，除了那个令我心烦的Content内容字段也被查询出来的问题，不过我也学会了，单独建立一个实体类，影射文章表的时候，不映射Content内容字段即可。很快发现，烦心的不止这个Content内容字段，如果要做到SQL那么灵活，要让系统更加高效，有很多地方实体类都不需要完整映射一个表的，一个表被影射出3-4个实体类是常见的事情，这让系统的实体类数量迅速膨胀... 看来我不能忍受ORM的这个毛病了，必须为ORM搞一个查询的API，让ORM可以查询指定的属性，而不是从数据库查询全部的属性数据出来，这就是OQL的雏形：
new User();
=new OQL(u);
&User& list=EntityQuery&User&.QueryList(q);
　　上面是查询年龄等于20的用户的ID，Name，Sex 信息，当然User 实体类还有其它属性，当前只需要这几个属性。
　　当时这个ORM查询API--OQL很简单，只能处理相等条件的查询，但是能够只选取实体类的部分属性，已经很好了，复杂点的查询，结合在XML中写SQL语句的方式解决，其它一些地方，通过数据控件，直接生成SQL语句去执行了，比如用数据控件来更新表单数据到数据库。
　　小结一下我做CRUD的历史，首先是对写SQL乐此不彼，还发明了在XML文件中配置SQL然后映射到程序的功能：SQL-MAP，然后觉得这样写SQL尽管方便管理编写查询且可以自动生成DAL代码，但是项目里面大量的SQL还是导致工作量很大，于是拿起ORM并发明了查询部分实体类属性的查询API：OQL；最后，觉得有些地方用ORM还是麻烦，比如处理一个表单的CRUD，如果用ORM也得收集或者填充数据到实体类上，还不如直接发出SQL，于是又有了"数据控件"。这样，按照出现的顺序，在2006年11月，一个具有SQL-MAP、ORM、Data Control功能的数据开发框架：PDF.NET Ver 1.0 诞生了！现在更名为，就是根据这个顺序过程来的。
2，Linq2Sql&EF：
　　2008年，随着.NET 3.5和VS2008发布，MS的官方ORM框架Linq2Sql也一同发布了，它采用Linq语法来查询数据库，也就是说Linq是MS的ORM查询API。由于Linq语法跟SQL语法有较大的区别，特别是Linq版本的左、又连接查询语法，跟SQL的Join连接查询，差异巨大，因此，学习Linq需要一定的成本。但是，LINQ to SQL是一个不再更新的技术。其有很多不足之处，如，不能灵活的定义对象模型与数据表之间的映射、无法扩展提供程序只能支持SQL Server等。 MS在同年，推出了Entity Framework，大家习惯的简称它为EF，它可以支持更多的数据库。于是在2008年12月，我原来所在公司的项目经理急切的准备去尝试它，用EF去开发一个用Oracle的系统。到了2009年8月，坊间已经到处流传，Linq2Sql将死，EF是未来之星，我们当时有一个客户端项目，准备用EF来访问SQLite。当时我任该项目的项目经理，由于同事都不怎么会Linq，更别提EF了，于是部分模块用传统的DataSet，部分用了EF for SQLite。结果项目做完，两部分模块进行对比，发现用EF的模块，访问速度非常的慢，查询复杂一下直接要5秒以上才出结果，对这些复杂的查询不得不直接用SQL去重写，而自此以后，我们公司再也没有人在项目中使用EF了，包括我也对EF比较失望，于是重新捡起我的PDF.NET,并在公司后来的诸多项目中大量推广使用。　　最近一两年，坊间流行DDD开发，提倡Code First了，谈论EF的人越来越多了，毕竟EF的查询API--LINQ，是.NET的亲生儿子，大家都爱上了它，那么爱EF也是自然的。在EF 5.0的时候，它已经完全支持Code First了，有人说现在的EF速度很快了，而我对此，还是半信半疑，全力发展PDF.NET,现在它也支持Code First 开发模式了。
3，微型ORM崛起
　　也是最近两年，谈论微型ORM的人也越来越多了，它们主打"灵活"、"高性能"两张牌，查询不用Linq，而是直接使用SQL或者变体的SQL语句，将结果直接映射成POCO实体类。由于它们大都采用了Emit的方式根据DataReader动态生成实体类的映射代码，所以这类微型ORM框架的速度接近手写映射了。这类框架的代表就是Dapper、PetaPOCO.
二、一决高下
2.1，ORM没有DataSet快？
2.1.1，ORM生成SQL的质量问题
　这个问题由来已久，自ORM诞生那一天起就有不少人在疑问，甚至有人说，复杂查询，就不该用ORM（见《》，不仅查询语法不灵活，性能也底下。对此问题，我认为不管是Linq，还是OQL，或者是别的什么ORM的查询API，要做到SQL那么灵活的确不可能，所以Hibernate还有HQL，EF还有ESQL，基于字符串的实体查询语句，但我觉得既然都字符串了还不如直接SQL来的好；而对于复杂查询效率低的问题，这个跟ORM没有太大关系，复杂查询哪怕用SQL写，DB执行起来也低的，ORM只不过自动生成SQL让DB去执行而已，问题可能出在某些ORM框架输出的SQL并不是开发人员预期的，也很难对它输出的SQL语句进行优化，从而导致效率较低，但这种情况并不多见，不是所有的查询ORM输出的SQL都很烂，某些SQL还是优化的很好的，只不过优化权不开在发人员手中。另外，有的ORM语言可以做到查询透明化的，即按照你用ORM的预期去生成对应的SQL，不会画蛇添足，PDF.NET的ORM查询语言OQL就是这样的。
2.1.2，DataReader没有DataSet快？
　　那么，对于一般的查询，ORM有没有DataSet快？
　　很多开发人员自己造的ORM轮子可能会有这个问题，依靠反射，将DataReader的数据读取到实体类上，这种方式效率很低，肯定比DataSet慢，现在，大部分成熟的ORM框架，对此都改进了，通常的做法是使用委托、表达式树、Emit来解决这个问题，Emit效率最高，表达式树的解析会消耗不少资源，早期的EF，不知道是不是这个问题，也是慢得出奇；而采用委托方式，有所改进，但效率不是很高，如果结合缓存，那么效率提升就较为明显了。
　　由于大部分ORM框架都是采用DataReader来读取数据的，而DataSet依赖于DataAdapter，本身DataReader就是比DataSet快的，所以只要解决了DataReader阅读器赋值给实体类的效率问题，那么这样的ORM就有可能比DataSet要快的，况且，弱类型的DataSet，在查询的时候会有2次查询，第一次是查询架构，第二次才是加载数据，所以效率比较慢，因此，采用强类型的DataSet，能够改善这个问题，但要使用自定义的Sql查询来填充强类型的DataSet的话，又非常慢，比DataSet慢了3倍多。
2，ORM的三个火枪手
　　要让ORM具有实用价值，那么必须解决性能问题，经过前面的分析，我们知道问题不在于DataReader本身是否比DataSet慢，而在于DataReader合适的数据读取方式与读取的值赋值给实体类的效率问题。前者已经有很多文章分析过，使用索引定位DataReader并进行类型化的读取是效率的关键，在本文"3.3.3，手写代码"里面做了最佳实践的示例；后者的问题，我们必须找到"三个火枪手"，来看他们如何避开直接反射，最快的实现给对象赋值？就是我们今天要讨论的问题。
　　OK，我们就以3个流行的框架，采用3种不同的方式实现的ORM ，来比较下看谁的效率最高。在比赛前，我们先分别看看3种ORM的实现方式。
2.1，委托+缓存
　　我们首先得知，对一个属性进行读写，可以通过反射实现，如下面的代码：
　　PropertyInfo 是对象的属性信息对象，可以通过反射拿到对象的每个属性的属性信息对象，我们可以给它定义一个委托来分别对应属性的读写：
Func&object, object[], object& Getter { get; privateset; }
Action&object, object, object[]& Setter { get; privateset; }
　　我们将Getter委托绑定到PropertyInfo.GetValue 方法上，将Setter委托绑定到PropertyInfo.SetValue 方法上，那么在使用的时候可以像下面这个样子：
mProperties[i];
(cp.SourceProperty.Getter != null)
Value = cp.SourceProperty.Getter(source, null); //PropertyInfo.GetValue(source,null);
(cp.TargetProperty.Setter != null)
null);// PropertyInfo.SetValue(target,Value ,null);
　　这段代码来自我以前的文章《》，类型的所有属性都已经事先缓存到了mProperties 数组中，这样可以在一定程度上改善反射的缺陷，加快属性读写的速度。
　　但是，上面的方式不是最好的，原因就在于PropertyInfo.GetValue、PropertyInfo.SetValue 很慢，因为它的参数和返回值都是 object 类型，会有类型检查和类型转换，因此，采用泛型委托才是正道。
MyFunc&T, P& GetValueD
MyAction&T, P& SetValueD
PropertyAccessor(Type type, string propertyName)
propertyInfo = type.GetProperty(propertyName);
(propertyInfo != null)
= (MyFunc&T, P&)Delegate.CreateDelegate(typeof(MyFunc&T, P&), propertyInfo.GetGetMethod());
= (MyAction&T, P&)Delegate.CreateDelegate(typeof(MyAction&T, P&), propertyInfo.GetSetMethod());
　　上面的代码定义了GetValueDelegate 委托，指向属性的 GetGetMethod()方法，定义SetValueDelegate，指向属性的GetSetMethod()方法。有了这两个泛型委托，我们访问一个属性，就类似于下面这个样子了：
GetUserNameValue&User&(User instance)
GetValueDelegate&User,string&(instance);
SetUserNameValue&User,string&(User instance,string newValue)
&User,string&(instance,newValue);
但为了让我们的方法更通用，再定义点参数和返回值是object类型的属性读写方法：
object GetValue(object instance)
GetValueDelegate((T)instance);
void SetValue(object instance, object newValue)
　　实验证明，尽管使用了这种方式对参数和返回值进行了类型转换，但还是要比前面的GetValue、SetValue方法要快得多。现在，将这段代码封装在泛型类 PropertyAccessor&T,P& 中，然后再将属性的每个GetValueDelegate、SetValueDelegate 缓存起来，那么使用起来效率就很高了：
INamedMemberAccessor FindAccessor(Type type, string memberName)
key = type.FullName + memberN
out accessor);
(accessor == null)
propertyInfo = type.GetProperty(memberName);
(propertyInfo == null)
new ArgumentException(实体类中没有属性名为的属性！
= Activator.CreateInstance(
(PropertyAccessor&,&).MakeGenericType(type, propertyInfo.PropertyType)
as INamedMemberA
　　有了这个方法，看起来读写一个属性很快了，但将它直接放到"百万级别"的数据查询场景下，它还是不那么快，之前老赵有篇文章曾经说过，这个问题有"字典查询开销"，不是说用了字典就一定快，因此，我们真正用的时候还得做下处理，把它"暂存"起来，看下面的代码：
static List&T& QueryList&T&(IDataReader reader) where T : class, new()
&T& list = new List&T&();
(reader.Read())
fcount = reader.FieldC
= new INamedMemberAccessor[fcount];
= new DelegatedReflectionMemberAccessor();
(int i = 0; i & i++)
= drm.FindAccessor&T&(reader.GetName(i));
= new T();
(int i = 0; i & i++)
(!reader.IsDBNull(i))
while (reader.Read());
　　上面的代码，每次查找到属性访问器之后，drm.FindAccessor&T&(reader.GetName(i))，把它按照顺序位置存入一个数组中，在每次读取DataReader的时候，按照数组索引拿到当前位置的属性访问器进行操作：
&accessors[i].SetValue(t, reader.GetValue(i));
　　无疑，数组按照索引访问，速度比字典要来得快的，字典每次得计算Key的哈希值然后再根据索引定位的。
就这样，我们采用泛型委托+反射+缓存的方式，终于实现了一个快速的ORM，PDF.NET Ver 5.0.3 加入了该特性，使得框架支持POCO实体类的效果更好了。
2.2，表达式树
有关表达式树的问题，我摘引下别人文章中的段落，原文在《表达式即编译器》：
微软在.NET 3.5中引入了LINQ。LINQ的关键部分之一（尤其是在访问数据库等外部资源的时候）是将代码表现为表达式树的概念。这种方法的可用领域非常广泛，例如我们可以这样筛选数据：
var query = fromcustin customerswhere cust.Region == "North"select
虽然从代码上看不太出彩，但是它和下面使用Lambda表达式的代码是完全一致的：
var query = customers.Where(cust =& cust.Region == "North");
LINQ 以及Where方法细节的关键之处，便是Lambda表达式。在LINQ to Object中，Where方法接受一个Func&T, bool&类型的参数&&它是一个根据某个对象（T）返回true（表示包含该对象）或false（表示排除该对象）的委托。然而，对于数据库这样的数据源来说，Where方法接受的是Expression&Func&T, bool&&参数。它是一个表示测试规则的表达式树，而不是一个委托。
这里的关键点，在于我们可以构造自己的表达式树来应对各种不同场景的需求&&表达式树还带有编译为一个强类型委托的功能。这让我们可以在运行时轻松编写IL。
&-------引用完------------
不用说，根正苗红的Linq2Sql，EntityFramework，都是基于表达式树打造的ORM。现在，EF也开源了，感兴趣的朋友可以去看下它在DataReader读取数据的时候是怎么MAP到实体类的。
现在很多声称速度接近手写的ORM框架，都利用了Emit技术，比如前面说的微型ORM代表Dapper。下面，我们看看Dapper是怎么具体使用Emit来读写实体类的。
Read the next grid of results
&/summary&
IEnumerable&T& Read&T&(bool buffered)
IEnumerable&T& Read&T&(bool buffered = true)
(reader == null) thrownew ObjectDisposedException(GetType().FullName, "The read this can happen after all data has been consumed");
(consumed) thrownew InvalidOperationException("Query results must be consumed in the correct order, and each result can only be consumed once");
typedIdentity = identity.ForGrid(typeof(T), gridIndex);
= GetCacheInfo(typedIdentity);
deserializer = cache.D
hash = GetColumnHash(reader);
(deserializer.Func == null || deserializer.Hash != hash)
= new DeserializerState(hash, GetDeserializer(typeof(T), reader, 0, -1, false));
result = ReadDeferred&T&(gridIndex, deserializer.Func, typedIdentity);
buffered ? result.ToList() :
　　在上面的方法中，引用了另外一个方法 GetDeserializer(typeof(T), reader, 0, -1, false) ，再跟踪下去，这个方法里面大量使用Emit方式，根据实体类类型T和当前的DataReader，构造合适的代码来快速读取数据并赋值给实体类，代码非常多，难读难懂，感兴趣的朋友自己慢慢去分析了。
　　据说，泛型委托的效率低于表达式树，表达式树的效率接近Emit，那么，使用了Emit，Dapper是不是最快的ORM呢？不能人云亦云，实践是检验真理的唯一标准！
三、华山论剑
3.1，参赛阵容
前面，有关ORM的实现原理说得差不多了，现在我们来比试非ORM，ORM它们到底谁才是"武林高手"。首先，对今天参赛选手分门别类：
老当益壮--DataSet、强类型DataSet,非ORM
如日中天--Entity Framework 5.0,ORM
西部牛仔派：
身手敏捷--Dapper,ORM
大成拳法--PDF.NET，混合型
藐视一切ORM，手写最靠谱
3.2，比赛内容
　　首先，在比赛开始前，会由EF的Code First 功能自动创建一个Users表，然后由PDF.NET 插入100W行随机的数据。最后，比赛分为2个时段，
第一时段，串行比赛，各选手依次进入赛场比赛，总共比赛10次；
比赛内容为，各选手从这100W行数据中查找身高大于1.6米的80后，对应的SQL如下：
UID,Sex,Height,Birthday,Name FROM Users Where Height &=1.6And Birthday&'
各选手根据这个比赛题目，尽情发挥，只要查询到这些指定的数据即可。
第二时段，并行比赛，每次有3位选手一起进行比赛，总共比赛100次，以平均成绩论胜负；
比赛内容为，查早身高在1.6-1.8之间的80后男性，对应的SQL如下：
UID,Sex,Height,Birthday,Name FROM Users
Height between1.6and1.8and sex=1And Birthday&''
比赛场馆由SqlServer 2008 赞助。
3.3，武功介绍
下面，我们来看看各派系的招式：
3.3.1，EF的招式：
不用解释，大家都看得懂
count = 0;
(var dbef = new LocalDBContex())
userQ = from user in dbef.Users
user.Height &= 1.6 && user.Birthday&new DateTime(1980,1,1)
= user.UID,
= user.Sex,
= user.Height,
= user.Birthday,
= user.Name
users = userQ.ToList();
3.3.1，DataSet 的招式：
这里分为2部分，前面是弱类型的DataSet，后面是强类型的DataSet
staticvoid TestDataSet(string sql, AdoHelper db, System.Diagnostics.Stopwatch sw)
"use DataSet,begin...");
= db.ExecuteDataSet(sql,
new IDataParameter[] {
"@height", 1.6),
"@birthday", new DateTime(1980, 1, 1))
"end,row count:{0},used time(ms){1}", ds.Tables[0].Rows.Count, sw.ElapsedMilliseconds);
使用强类型的
"use Typed DataSet,begin...");
new DataSet1();
= db as SqlS
new IDataParameter[] {
"@height", 1.6),
"@birthday", new DateTime(1980, 1, 1))
下面的方式使用强类型，但是没有制定查询条件，可能数据量会很大，不通用
"end,row count:{0},used time(ms){1}", ds.Tables[0].Rows.Count, sw.ElapsedMilliseconds);
3.3.3，手写代码：
根据具体的SQL，手工写DataReader的数据读取代码，赋值给实体类
格式化查询
new UserPoco()
= reader.GetInt32(0),
= reader.GetBoolean(1),安全的做法应该判断
= reader.GetDateTime(3),
= reader.IsDBNull(0) ? null : reader.GetString(4)
,new DateTime(1980,1,1)
3.3.4，采用泛型委托：
直接使用SQL查询得到DataReader，在实体类MAP的时候，此用泛型委托的方式处理，即文章开头说明的原理
staticvoid TestAdoHelperPOCO(string sql, AdoHelper db, System.Diagnostics.Stopwatch sw)
"use PDF.NET AdoHelper POCO,begin...");
&UserPoco& list = AdoHelper.QueryList&UserPoco&(
IDataParameter[] {
"@height", 1.6),
"@birthday", new DateTime(1980, 1, 1))
"end,row count:{0},used time(ms){1}", list.Count, sw.ElapsedMilliseconds);
PDF.NET Sql2Entity:
直接使用SQL，但将结果映射到PDF.NET的实体类
.QueryList(
new IDataParameter[] {
"@height", 1.6),
"@birthday", new DateTime(1980, 1, 1))
3.3.6，IDataRead实体类：在POCO实体类的基础上，实现IDataRead接口，自定义DataReaer的读取方式
staticvoid TestEntityQueryByIDataRead(string sql, AdoHelper db, System.Diagnostics.Stopwatch sw)
"use PDF.NET EntityQuery, with IDataRead class begin...");
&UserIDataRead& list3 = EntityQuery.QueryList&UserIDataRead&(
new IDataParameter[] {
"@height", 1.6),
"@birthday", new DateTime(1980, 1, 1))
"end,row count:{0},used time(ms){1}", list3.Count, sw.ElapsedMilliseconds);
其中用到的实体类的定义如下：
class UserIDataRead : ITable_User, PWMIS.Common.IReadData
实现接口的属性成员代码略
void ReadData(System.Data.IDataReader reader, int fieldCount, string[] fieldNames)
(int i = 0; i & fieldC i++)
(reader.IsDBNull(i))
(fieldNames[i])
"UID": this.UID = reader.GetInt32(i); break;
"Sex": this.Sex = reader.GetBoolean(i); break;
"Height": this.Height = reader.GetFloat(i); break;
"Birthday": this.Birthday = reader.GetDateTime(i); break;
"Name": this.Name = reader.GetString(i); break;
3.3.7，PDF.NET OQL:
使用框架的ORM查询API--OQL进行查询
staticvoid TestEntityQueryByOQL(AdoHelper db, System.Diagnostics.Stopwatch sw)
"use PDF.NET OQL,begin...");
=new Table_User ();
= OQL.From(u)
=& cmp.Property(u.Height) &= 1.6 & cmp.Comparer(u.Birthday,"&",new DateTime(1980,1,1)))
&Table_User& list3 = EntityQuery&Table_User&.QueryList(q, db);
"end,row count:{0},used time(ms){1}", list3.Count, sw.ElapsedMilliseconds);
3.3.8，PDF.NET OQL&POCO:
使用OQL构造查询表达式，但是将结果映射到一个POCO实体类中，使用了泛型委托
staticvoid TestEntityQueryByPOCO_OQL(AdoHelper db, System.Diagnostics.Stopwatch sw)
"use PDF.NET OQL with POCO,begin...");
= new Table_User();
= OQL.From(u)
=& cmp.Property(u.Height) &= 1.6 & cmp.Comparer(u.Birthday, "&", new DateTime(1980, 1, 1)))
&UserPoco& list3 = EntityQuery.QueryList&UserPoco&(q, db);
"end,row count:{0},used time(ms){1}", list3.Count, sw.ElapsedMilliseconds);
3.3.9，PDF.NET SQL-MAP:
将SQL写在XML配置文件中，并自动生成DAL代码首先看调用代码：
staticvoid TestSqlMap(System.Diagnostics.Stopwatch sw)
"use PDF.NET SQL-MAP,begin...");
= new SqlMapDAL.TestClassSqlServer();
&Table_User& list10 = tcs.QueryUser(1.6f,new DateTime(1980,1,1));
"end,row count:{0},used time(ms){1}", list10.Count, sw.ElapsedMilliseconds);
然后看看对应的DAL代码：
使用该程序前请先引用程序集：，并且下面定义的名称空间前缀不要使用ＰＷＭＩＳ，更多信息，请查看
System.Collections.G
PWMIS.DataMap.SqlM
PWMIS.DataMap.E
DBQueryTest.SqlMapDAL
创建时间：
用途描述：测试
其它信息：该文件由自动生成，修改前请先备份！
&/summary&
partialclass TestClassSqlServer
默认构造函数
&/summary&
TestClassSqlServer()
= "TestSqlServer";
文件嵌入的程序集名称和资源名称，如果有多个文件建议在此指明。
查询指定身高的用户
&/summary&
&param name="height"&&/param&
&returns&&/returns&
List&LocalDB.Table_User& QueryUser(Single height, DateTime birthday)
获取命令信息
"QueryUser");
参数赋值，推荐使用该种方式；
0].Value =
1].Value =
参数赋值，使用命名方式；
EntityQuery&LocalDB.Table_User&.QueryList( CurrentDataBase.ExecuteReader(CurrentDataBase.ConnectionString, cmdInfo.CommandType, cmdInfo.CommandText , cmdInfo.DataParameters));
//End Function
//End Class
//End NameSpace
最后，看看对应的SQL的XML配置文件：
xml version="1.0" encoding="utf-8"?&
SqlMap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SqlMap.xsd"
="DBQueryTest,DBQueryTest.SqlMap.config"&
Script Type="Access" Version="03"&
查询指定身高的用户="EntityList" ResultMap="LocalDB.Table_User"&
CommandClass&
Script Type="SqlServer" Version="2008" ConnectionString=""&
查询指定身高的用户="EntityList" ResultMap="LocalDB.Table_User"&
CommandClass&
3.3.10 Dapper ORM：
使用Dapper 格式的SQL参数语法，将查询结果映射到POCO实体类中
staticvoid TestDapperORM(string sql, System.Diagnostics.Stopwatch sw)
"use Dapper ORM,begin...");
= new SqlConnection(MyDB.Instance.ConnectionString);
&UserPoco& list6 = connection.Query&UserPoco&(sql, new { height = 1.6, birthday=new DateTime(1980,1,1) })
&UserPoco&();
"end,row count:{0},used time(ms){1}", list6.Count, sw.ElapsedMilliseconds);
3.3.11 并行测试的招式：
由EF，PDF.NET OQL,Dapper ORM参加，使用Ｔａｓｋ开启任务。下面是完整的并行测试代码
ParalleTest
long efTime = 0;
long pdfTime = 0;
long dapperTime = 0;
int batch = 100;
void StartTest()
"Paraller Test ,begin....");
(int i = 0; i & i++)
task1 = Task.Factory.StartNew(() =& TestEF());
task2 = Task.Factory.StartNew(() =& TestPDFNetOQL());
task3 = Task.Factory.StartNew(() =& TestDapperORM());
"----tested No.{0}----------",i+1);
"EF used all time:{0}ms,avg time:{1}", efTime, efTime / batch);
"PDFNet OQL used all time:{0}ms,avg time:{1}", pdfTime, pdfTime/batch);
"Dapper ORM used all time:{0}ms,avg time:{1}", dapperTime, dapperTime/batch);
"Paraller Test OK!");
void TestEF()
= new System.Diagnostics.Stopwatch();
(var dbef = new LocalDBContex())
userQ = from user in dbef.Users
true && user.Birthday & new DateTime(1980, 1, 1)
= user.UID,
= user.Sex,
= user.Height,
= user.Birthday,
= user.Name
users = userQ.ToList();
"EF used time:{0}ms.",sw.ElapsedMilliseconds);
+= sw.ElapsedM
void TestPDFNetOQL()
= new System.Diagnostics.Stopwatch();
= new Table_User() { Sex=true };
= OQL.From(u)
=& cmp.Between(u.Height,1.6,1.8)
cmp.EqualValue(u.Sex)
"&", new DateTime(1980, 1, 1))
&Table_User& list3 = EntityQuery&Table_User&.QueryList(q);
"PDFNet ORM(OQL) used time:{0}ms.", sw.ElapsedMilliseconds);
+= sw.ElapsedM
void TestDapperORM()
sql = @"SELECT UID,Sex,Height,Birthday,Name FROM Users
= new System.Diagnostics.Stopwatch();
= new SqlConnection(MyDB.Instance.ConnectionString);
&UserPoco& list6 = connection.Query&UserPoco&(sql,
{ P1 = 1.6,P2=1.8,P3=true,P4 = new DateTime(1980, 1, 1) })
&UserPoco&();
"DapperORM used time:{0}ms.", sw.ElapsedMilliseconds);
+= sw.ElapsedM
3.4，场馆准备
为了更加有效地测试，本次测试准备100W行随机的数据，每条数据的属性值都是随机模拟的，包括姓名、年龄、性别、身高等，下面是具体代码：
staticvoid InitDataBase()
利用自动创建表
count = 0;
dbef = new LocalDBContex();
tempUser= dbef.Users.Take(1).FirstOrDefault();
= dbef.Users.Count();
"check database table [Users] have record count:{0}",count);
如果没有万条记录，插入该数量的记录
(count & 1000000)
"insert 1000000 rows data...");
= new System.Diagnostics.Stopwatch();
下面的等同于它默认取最后一个连接配置
"default");
(var session = db.OpenSession())
&Table_User& list = new List&Table_User&();
innerCount = 0;
(int i = i & 1000000; i++)
= new Table_User();
= Util.CreateUserName();
= Util.CreatePersonHeight();
= Util.CreatePersonSex();
=Util.CreateBirthday();
(innerCount & 10000)
= EntityQueryAnonymous.EntitysToDataTable&Table_User&(list);
"{0}:inserted 10000 rows .",DateTime.Now);
(list.Count & 0)
= EntityQueryAnonymous.EntitysToDataTable&Table_User&(list);
0].GetTableName(), innerCount);
"{0}:inserted {1} rows .", DateTime.Now, innerCount);
"Init data used time:{0}ms",sw.ElapsedMilliseconds);
"check database ok.");
要使用它，得先准备一下配置文件了，本测试程序使用EF CodeFirst& 功能，所以配置文件内容有所增加：
xml version="1.0" encoding="utf-8"?&
configuration&
configSections&
section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c" requirePermission="false"/&
configSections&
connectionStrings&
add name="LocalDBContex" connectionString="Data Source=.;Initial Catalog=LocalDB;Persist Security Info=TIntegrated Security=SSPI;"
="System.Data.SqlClient"/&
add name="default" connectionString="Data Source=.;Initial Catalog=LocalDB;Integrated Security=True"
="SqlServer"/&
add name="DBQueryTest.Properties.Settings.LocalDBConnectionString"
="Data Source=.;Initial Catalog=LocalDB;Integrated Security=True"
="System.Data.SqlClient"/&
connectionStrings&
supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/&
entityFramework&
defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework"/&
entityFramework&
configuration&
系统配置中，要求使用SqlServer数据库，且实现创建一个数据库 LocalDB,如果数据库不在本地机器上，需要修改连接字符串。
四、水落石出
4.1，谁可能是高手？
经过上面的准备，你是不是已经很急切的想知道谁是绝顶高手了？
EF，它的执行效率长期被人诟病，除了大部分人认为开发效率No.1之外，没有人相信它会是冠军了，今天它会不会是匹黑马呢？
Dapper，身手敏捷，兼有SQL的灵活与ORM的强大，加之它是外国的月亮，用的人越来越多，有点要把EF比下去的架势，如日中天了！
PDF.NET，本土草根，本着"中国的月亮没有外国的圆"的传统观念，不被看好。
Hand Code，借助PDF.NET提供的SqlHelper（AdoHelper）来写的，如果其它人比它还快，那么一定是运气太差，否则，其它人都只有唯它"马首是瞻"的份！
4.2，串行测试
比赛开始，第一轮，串行比赛，下面是比赛结果：
Dapper Test.
,if OK then continue.
[Users] have record count:1000000
,Sex,Height,Birthday,Name FROM Users Where Height &=1.6 And Birthday&''
.1----------------
,begin...end,row count:300135,used time(ms)1098
,begin...end,row count:300135,used time(ms)2472
,begin...end,row count:300135,used time(ms)3427
,begin...end,row count:300135,used time(ms)438
,begin...end,row count:300135,used time(ms)568
,begin...end,row count:300135,used time(ms)538
, with IDataRead class begin...end,row count:300135,used time(ms)432
,begin...end,row count:300135,used time(ms)781
,begin...end,row count:300135,used time(ms)639
,begin...end,row count:300135,used time(ms)577
,begin...end,row count:300135,used time(ms)1088-------------Testt No.2----------------
,begin...end,row count:300135,used time(ms)364
,begin...end,row count:300135,used time(ms)1017
,begin...end,row count:300135,used time(ms)3168
,begin...end,row count:300135,used time(ms)330
,begin...end,row count:300135,used time(ms)596
,begin...end,row count:300135,used time(ms)555
, with IDataRead class begin...end,row count:300135,used time(ms)445
,begin...end,row count:300135,used time(ms)555
,begin...end,row count:300135,used time(ms)588
,begin...end,row count:300135,used time(ms)559
,begin...end,row count:300135,used time(ms)534
.3----------------
,begin...end,row count:300135,used time(ms)346
,begin...end,row count:300135,used time(ms)1051
,begin...end,row count:300135,used time(ms)3195
,begin...end,row count:300135,used time(ms)305
,begin...end,row count:300135,used time(ms)557
,begin...end,row count:300135,used time(ms)549
, with IDataRead class begin...end,row count:300135,used time(ms)456
,begin...end,row count:300135,used time(ms)664
,begin...end,row count:300135,used time(ms)583
,begin...end,row count:300135,used time(ms)520
,begin...end,row count:300135,used time(ms)543
由于篇幅原因，这里只贴出前3轮的比赛成绩，比赛结果，EF居然是匹黑马，一雪前耻，速度接近手写代码，但是EF，Dapper,第一轮比赛竟然输给了PDF.NET OQL,而Dapper后面只是略胜，比起PDF.NET POCO,也是略胜，看来泛型委托还是输给了Emit，而EF,Dapper，它们在第一运行的时候，需要缓存代码，所以较慢。多次运行发现，EF仅这一次较慢，以后数次都很快，看来EF的代码缓存策略，跟Dapper还是不一样。
但是，Dapper居然输给了EF，这是怎么回事？莫非表达式树比Emit还快？还是EF将结果缓存了？使用SqlServer事务探察器，发现EF的确每次发出了查询，没有缓存数据。看来EF5.0的表达式树可能真是效率有了很大提升，并且EF做了很好的优化，对EF取得的成果，不得不叹服！
下面是10次串行测试的数据表：
数据访问模式
EF CodeFirst
Typed DataSet
PDF.NET AdoHelper HandCode
PDF.NET AdoHelper POCO
PDF.NET EntityQuery
PDF.NET IDataRead
PDF.NET OQL
PDF.NET OQL with POCO
PDF.NET SQL-MAP
由于Type DataSet差异过大，在下面的图中去掉了：
下面是平均值图形：
4.3，并行测试
下面是并行测试结果，程序共运行100次，每次三种ORM框架同时运行。由于篇幅原因，这里只贴出最后三次的测试数据和最后计算的每种框架的性能平均数。
----tested No.97----------
DapperORM used time:435ms.
EF used time:462ms.
PDFNet ORM(OQL) used time:466ms.
----tested No.98----------
PDFNet ORM(OQL) used time:383ms.
DapperORM used time:389ms.
EF used time:451ms.
----tested No.99----------
PDFNet ORM(OQL) used time:390ms.
DapperORM used time:445ms.
EF used time:456ms.
----tested No.100----------
EF used all time:44462ms,avg time:444
PDFNet OQL used all time:38850ms,avg time:388
Dapper ORM used all time:39127ms,avg time:391
Paraller Test OK!
经过数次测试发现，三种框架表现都很优异，差距很小，其中PDF.NET OQL略微胜出，Dapper次之，EF稍慢。
EF Code First
PDF.Net OQL
Dapper ORM
并行测试耗时百分比
　　串行测试，EF5.0 胜出，并行测试，PDF.NET胜出。在实际运行环境中，并行测试可能更好的反映问题。但是两种测试场景，它们各自之见的性能并没有"量"的差距，因此我们选择具体的成熟的ＯＲＭ的时候，性能并不是一个主要考察依据，而应该综合分析比较，比如以下问题：
源码规模是否较小，容易掌握；
源码是否有充分的注释，对于国人而言是否有完整的中文注释；
源码是否符合国人的习惯，简单，易于理解；
使用是否方便，用户代码是否最少；
是否能够支持.NET 2.0 框架；
是否能够跨平台，比如在Linux上运行；
是否支持所有的Ado.NET支持的数据库；
是否有社区支持，能够得到框架团队的直接支持。
为什么要选择ＰＤＦ．ＮＥＴ框架？
喜欢简单的开发过程！
老板逼的急，要快速开发完成！
喜欢ORM框架！
喜欢存储过程+手写SQL的开发方式，更有"安全感"！
希望像写SQL那样来操作ORM框架！
EF、NH等框架在我的项目中某些特性没法完全满足，想定制修改或者扩展，但没有源码或者源码规模巨大！
程序复杂，执行要快！
团队中有人喜欢拖控件，有人喜欢写SQL，也有人喜欢ORM，众口难调，作为Leader，不知道如何是好！
项目大，为确保成功，需要掌控所有的细节，包括ORM等数据访问的细节！
系统需要移植到新的数据库系统，但原来的系统手写了很多特定数据库平台的SQL语句，没法移植！
&　　框架是我们多年开发经验的总结，在众多流行的开发框架下，相信你选择PDF.NET没错！
开源基金：
　　中国的软件开源事业需要更多的人的关心和支持，PDF.NET为此在2011年开始加入开源行列，并在2012年国庆前对最新版本进行开源，希望国人在基础开发框架方面有更多的选择，促进中国软件事业的发展。但PDF.NET出身草根，它的发展需要您的更多呵护。如果您觉得它的确为你的软件开发起到了帮助，并且愿意更进一步的支持框架的发展，请捐助PDF.NET，我们将使用这笔资金来进行框架的宣传、推广、培训活动；支付框架所在网站、源代码托管服务；组织开发活动，奖励开发团队的贡献。&&& 有关抗震救灾和捐助的详细信息，请参看框架官网http://www.pwmis.com/sqlmap介绍，请以官网公布的信息为准！感谢所有已经捐助过和关心PDF.NET的朋友，期望他们的爱心能够让更多的人知晓并赞扬！
关于本文：
本文中使用的测试程序下载：
时间：日星期日}