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的递归查询更好。

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

1 个答案: