#T#在网上看到一篇文章是关于讲解ADO.NET Entity框架。看了之后深有体会，在这里我就把我所看到的和大家在一起分享一下。ADO.NET团队最近讨论了ADO.NET Entity框架的各种性能特征。ADO.NET Entity框架在12月已经进入它的第三个beta版本，自那时起开发团队就开始为开发人员提供了使用该框架的相关信息。而现在，则为开发人员提供了框架性能方面的信息。
本文鞭辟入里地介绍了ADO.NET Entity框架的性能，演示了如何提高简单查询速度的方法，并阐释了框架的性能特征。需要重点指出的是，当一个抽象层或者类似EDM（译注：指Entity Data Model）的模块被用来转换数据库的关系样式时，会带来一定的性能损失。
查询与结果
本文使用了NorthWind数据库作为模型，并创建了一个简单查询：
- (NorthwindEntities ne = NorthwindEntities()) { (Order o ne.Orders) { i = o.OrderID; } }
测试时，我们的每个查询对整个848行数据进行了10次遍历。结果很有意思，第1次运行时耗费了4241毫秒，而接下来的每次运行则平均耗费13毫秒左右的时间。最耗时的一部分内容是ObjectContext的创建，而在执行任意一个访问数据库的操作时，都会有一些耗时的操作发生。耗时百分比值最大的是视图生成，它达到了惊人的56%。既然视图生成是造成性能损耗的罪魁祸首，那么开发人员最好是使用命令行工具EDM生成器（EdmGen.exe），运行时需要加上视图生成命令参数（/mode:ViewGeneration），它的输出内容为一个代码文件（C#或者VB.NET），可以包含在项目中。视图的预生成可以将启动时间降低到2933毫秒，而对于循环遍历操作，整个时间可以降低28%。生成视图并随着应用程序一起发布是提高性能的妙方，但其缺点则在于视图不再是动态的，一旦模型发生改变，就需要重新生成以保持同步。
ADO.NET Entity框架查询性能
需要指出的是关于性能的主要设计要素是查询缓存。一旦执行了查询，它的一部分内容就被维持在全局缓存中。由于查询与元数据缓存的存在，使得第二次运行的执行速度总是比第一次运行快。例如，如下的Entity SQL查询：
- (PerformanceArticleContext ne = PerformanceArticleContext())
- { ObjectQuery<Orders> orders = ne.CreateQuery<Orders>();
- (Orders o orders) { i = o.OrderID; } }
第一次运行该查询耗时179毫秒，但下一次运行则只耗费了15毫秒的时间。首次运行与后续运行在执行方面的区别在于它构建了能够为执行传递provider的命令树（command tree）。
ADO.NET Entity框架之LINQ查询在执行方式上与Entity SQL查询相似。例如，下面的查询：
- (PerformanceArticleContext ne = PerformanceArticleContext())
- { var orders = from order ne.Orders select order;
- (Orders o orders) { i = o.OrderID; } }
首次执行LINQ查询耗时202毫秒，而随后的执行耗时18毫秒，两者的差距还要低于Entity SQL。可以看到，使用编译了的LINQ查询对于性能的提高更为明显。编译LINQ查询的好处在于它构建了表达树（expression tree），当查询被编译时，后续的执行就不需要重建表达树了。编译的LINQ查询代码看起来像这样：
- Func<PerformanceArticleContext, IQueryable<Orders>> compiledQuery
= CompiledQuery.Compile((PerformanceArticleContext ne) => (from o ne.Orders select o));- (PerformanceArticleContext ne = PerformanceArticleContext()) { (Orders o compiledQuery(ne)) { i = o.OrderID; } }
注意，PerformanceArticleContext是一个委托。对于编译了的LINQ查询而言，第一次执行耗时305毫秒，而随后的执行时间则为15毫秒。结果并不惊人，值得关注的是编译的LINQ查询比之常规方式的LINQ查询，执行时间少了3毫秒。或许对于几个查询而言，这算不上什么，但如果有数以千计的查询，这样的性能提升就倍显价值所在了。
