实体框架和linq到实体的性能

Question

我一直在调查使用Microsoft的实体框架来处理工作中的项目。 我创建了一个简单的小数据层解决方案，它具有IDataService接口，因此我可以使用Linq-to-Entity编写标准的ADO.Net实现和实体框架版本。

我创建了两个测试请求完全相同的数据，但使用不同的实现。 查询很简单，它们从表中检索数据，并使用分层信息生成带有层次结构中数据的DTO。

数据库中的数据符合以下几行

------------------------
ID  | Description
----|-------------------
1   | Item 1
2   | Item 2
3   | Item 3
4   | Item 4
5   | Item 5

----------------
Parent | Child  
-------|--------
1      | 2
1      | 3
3      | 4
1      | 5

Desired Output
--------------
Item 1
|-Item 2
|-Item 3
| |-Item 4 
|-Item 5

所以查询目前采取以下形式：

from a in tableA
join b in tableB on b.Parent equals a.ID
where b.Parent == root.ID
select new DTO.Entry {
  Id = a.ID
  ...
}

包含此查询的方法以递归方式运行，直到不再有子元素要处理。

使用Linq-to-entity，测试大约需要320ms才能完成，使用ADO.Net测试大约需要8ms！

这只是我必须要考虑的因素，还是应该与性能相提并论？ 此外，由于底层数据结构没有参照完整性（我知道！），所以我在我的ADO.Net中补偿了这一点，但我不能与实体一起，这可能会产生影响吗？

目前似乎如果你想要性能，那么你应该坚持使用ADO.Net

Answer 1

询问客户：您想要更多性能还是更少的错误？

当然，普通的ADO.Net比使用ADO.Net的数据层表现更好，但在此之前和之后做得更多。 此外，在效率方面，您选择了EF不是一个好竞争者的领域：递归查询。 但一般来说，当谈到编写正确，稳定的代码以实现可接受的时候 ，EF（或任何经验丰富的OR映射器）都会比ADO.Net高出一筹。 它是手写的SQL和数据驱动编程与linq和面向对象的编程。

不过，你说对了

目前似乎如果你想要性能，那么你应该坚持使用ADO.Net

当然，对于性能关键的操作或者，映射器往往有太多的内部开销来满足要求。 并返回递归查询：没有什么比数据库中的CTE更好的递归查询。