由于很多园友反馈，有的组件不应该缺席、测试复杂度不够、测试还缺乏一定的公平。

因此考虑在下一个版本中，确保在更加公平的前提下进行更高复杂度的测试 。

同时将分为2组测试，纯SQL组件及纯ORM组件， 如果纯SQL组件不足，就只进行纯ORM组件的测试。

待加入测试组件有Dapper、PetaPoco/NPoco、Elinq、FluentData ，有更好的建议，请留言。

--------------------------------------------------------------

“啊！你在用ORM？会不会性能很差啊？”

标题提到的组件“增删改查”都实现了测试代码，所以除了测试外，也可以把此项目作为各个组件的入门参考demo。

源码下载：https://github.com/alifellod/DbAccessLibTest/archive/master.zip

git地址：https://github.com/alifellod/DbAccessLibTest  欢迎园友贡献改进代码。

项目使用的是.Net Framework 4.0可以使用2010或2012打开。

默认测试数据库使用SqlServer

测试前，请先创建数据表Test（使用名为Test的数据库，如果不用这个数据库，请更改数据库连接字符串）

CREATE TABLE [dbo].[Test]
(
    [RowId] [int] IDENTITY(1,1) NOT NULL,
    [Guid] [varchar](50) primary key NOT NULL,
    [Content] [nvarchar](500) NULL,
    [CreateDate] [datetime] NULL default getdate(),
    [EditDate] [datetime] NULL
)

此程度测试代码使用了接口规范，并没有为了省事耦合在程序里，因此编写修改测试代码非常简单，所以也希望各位园友自己写上一段测试测试。
由于这些组件基本都是第一次使用，所以可能导致部分组件测试代码编写并不合理，敬请指点。
注意：各组件的测试均采用一样的测试思路，也即ORM对ORM，SQL对SQL，循环也是一样的循环。
不必拘泥于15和23的区别，而是要区别10和100的区别，也就是在一个数量级别之间比较。
线程我分别写了Task、ThreadPool和Thread的执行方式，根据自己的喜欢选择。

测试之前，可先预热一下——各个组件进行一定数量查询。

先看两张测试图。

分别是ClownFish和EF的测试图，X轴是线程名称，Y轴是耗时。

特别说明: CYQ的数据是使用更新前的组件，在昨晚测试整理的。今天收到秋天园友的反馈，已经在git提交了更新，测试的数据也回归正常。

因此，数据也调整过来。（2013-07-27 13:53）

关于XCode的测试数据，请参看大石头的说明。大石头建议在大数据的访问时使用此组件，并开启缓存。

同时不再接受新的组件更新，除非是在新的测试版本中，以避免针对性的更新。

数据格式：平均值-最高值-最低值
测试顺序：增、改、删
100“线程” 查询10次 增删改

1000“线程” 查询10次增删改

查询测试，数据行100W
100“线程” 查询返回Top 100
使用没有索引的列RowId排序

查询采用的根据组件提供的分页或者Top查询功能。(moon及xcode使用的是分页查询)
使用没有索引的列RowId排序

使用有索引的列Guid排序

经过测试，发现线程越多，越容易出现问题“超时时间已到，但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用，并且达到了最大池大小。”导致访问很不稳定。
一个好的数据访问层应该是可以优雅的接受并处理大并发的访问，而不应该仅仅只盯住表面上的测试数据（除非有数量级上的差距）。
整个程序框架怎么才设计出色，更加优雅的面对请求，才是应该花更多心思去考虑的。
从上面也可以看到，ORM性能其实并没有一般人想象的那么糟糕。

最后看看程序的代码是怎么样的。

项目目录

测试代码接口

 View Code

ClownFish-SQL测试代码

 View Code

 View Code

PDF-SQL测试代码

 View Code

CYQ-ORM测试代码

 View Code

EF-ORM测试代码

 View Code

Moon-ORM测试代码

 View Code

MySoft-ORM测试代码

 View Code

NHibernate-ORM测试代码

 View Code

PDF-ORM测试代码

View Code

XCode-ORM测试代码

 View Code

测试耗时监控

 View Code

测试完整逻辑代码 ，300多行，慎点。

 View Code

到底是选择ORM而不写Sql，还是 为了追求性能，而避开ORM，就看自己的情况来取舍了。

选择一个组件的时候，可以考虑这几方面：稳定性、性能、易用性、是否保持更新、是否有较好的文档手册、使用者社区怎么样、是否开源。

上面提供的组件测试代码也可以看到这些组件的代码风格，喜欢语法糖的不妨好好看看，到底更喜欢哪种风格。

综合考虑选择。

QQ交流群：9524888 ，如果想提交测试代码，可以直接发给我，我加上去。

更新修正说明：

由于ClownFish提出测试的时候，使用了匿名对象，因此修改为SQL的直接执行，测试数据如下。

由于1000线程的测试，在500左右，就出现连接超时问题，不能提供测试数据，有兴趣的朋友，自己运行测试。对此造成误解，请谅解。

本文转自火地晋博客园博客，原文链接：http://www.cnblogs.com/yelaiju/p/3209506.html，如需转载请自行联系原作者