0

我一直在研究将 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 测试大约需要 320 毫秒才能完成，使用 ADO.Net 测试大约需要 8 毫秒！

这只是我必须忍受/考虑的事情，还是表现应该差不多？此外，由于底层数据结构没有参照完整性（我知道！），所以我在我的 ADO.Net 内容中对此进行了补偿，但我不能使用实体，这可能会产生影响吗？

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

4

1 回答 1

2

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

当然，普通的 ADO.Net 比同样使用 ADO.Net 的数据层表现得更好，但在此之前和之后的表现要好得多。此外，您选择了 EF 在效率方面不是很好的竞争对手的领域：递归查询。但一般来说，在编写正确、稳定且性能可接受的代码时，EF（或任何经验丰富的 OR 映射器）在 ADO.Net 上遥遥领先。它是手写 SQL 和数据驱动编程与 linq 和面向对象编程。

不过，你说得对

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

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

于 2012-08-19T21:48:06.313 回答