用于在某个时候只返回一页记录的技术之一是建立一个SQL语句，该语句包含一个WHERE和ORDER BY子句，并有TOP判定。这种技术依赖于识别每个唯一行的方法，那么，Oracle是否有计划给Visual Studio编写独特的ADO.Net性能呢？
测试环境当然就是我这台笔记本了，受限与硬盘转速，运行起来一定是不如台式机的，但至少保证了三个方案相同的软硬件环境：Windows Server 2008，Visual Studio 2008，MS SQL Server 2008，清一色的***产品。
测试分成六个阶段，数据量分别为10，10，100，1千，1万，10万逐级增长，分别测试了读取、写入、更改、删除四个基本的操作的耗时，结果如下（时间单位：秒）：
| ***次读写10条数据 | |||||
| 读写方式 | 读取耗时 | 添加耗时 | 修改耗时 | 删除耗时 | 平均耗时 |
| 当前机制(简化) | 0.007 | 0.35 | 0.02 | 0.014 | 0.09775 |
| LINQ to SQL | 0.023 | 0.083 | 0.102 | 0.068 | 0.069 |
| Entity Framework | 0.238 | 3.084 | 0.009 | 0.006 | 0.83425 |
***阶段测试结果非常出人意料，ADO.Net性能和LINQ to SQL操作数据的时间都控制在0.5秒以内，非常的迅速，但是Entity Framework在添加这步表现非常差，由于这五步是连续测试，其中添加数据是***步操作，而EF在在进行***步操作的时候足足延迟了3秒钟！这3秒钟 到底EF在做什么？
从第二阶段开始，性能的优劣就非常明显的展现在我们面前，第二阶段到第六阶段，不论操作数据量的大小，图中的耗 时比例几乎是相同的。Entity Framework无可争议的以极高的效率在三种方案中脱颖而出，而LINQ to SQL的龟速修改和删除操作消耗的时间几乎是EF的10倍，ADO.Net性能在添加数据上的表现实在不尽如人意，这也跟我们项目底层写法有关。 #t#
从上面的测试结果可以看出，除去EF在初次操作数据是延迟的3秒钟（初步认为是初始化时间），EF的平均效率是LINQ to SQL的6倍，是当前项目机制的4倍，这是非常可观的效率提升，不难理解为什么微软几乎放弃了LINQ to SQL，全力支持EF了。
