EF 或 ADO.Net (SqlCommand & SqlConnetion) 以及那些性能用法

Question

取决于我在 EF（和 LinQ）上 7 个月的研究和工作，似乎 EF（或 LinQ）是用传统解决方案替换它的好解决方案（我的意思是使用 SqlCommand、SqlConnetion、DataReader 和其他 ADO。网络组件）

这里我有 3 个问题：

1. 无论 EF 和它的性能使用情况如何，用 EF 完全替代传统解决方案有什么我应该担心的吗？

2. 看看这两个代码：

---

//#1
var UsersEnum = MyDataContext.Users;
return UserEnum.Where(obj => obj.age > 20);

//#2
return MyDataContext.Users.Where(obj.age > 20);

这两个代码有什么区别？！！

第一个on，先获取所有记录并存储在变量中，然后按age过滤，然后返回剩余记录

但是第二个呢？它会获取所有记录然后过滤它们吗？或者它只获取过滤后的记录（不是全部）？！

---

3 .在性能使用中，这些牵引代码有什么不同？有什么区别吗？或者一般来说，似乎 EF 对 ADO.Net 组件的性能更高。对吗？

对不起，我的语法不好，我是英语新手，感谢您的关注。任何想法和建议都会很有用。

Answer 1

无论 EF 和它的性能使用情况如何，我有什么需要 应该担心用 EF 替换传统解决方案 完全吗？

EF 是对 ADO.NET 的抽象。抽象是泄漏的。您将失去 ADO.NET API 的某些功能，但如果您的所有要求都很好地满足 EF 的容量，那么您就可以了。使用 EF 会错过的一些示例是批量插入和批量查询。 就性能而言，EF 并不是批处理相关操作的好解决方案。它擅长处理少量对象。

这两个代码有什么区别？！

这两个代码示例在功能方面没有区别。他们都不会发出数据库请求。这是 LINQ 的一个特性，称为 Differed Execution

这两个代码在性能使用上有什么不同？是 有什么区别吗？或者一般来说，似乎 EF 获得了更多的性能 针对 ADO.Net 组件。对吗？

如果 20ms、30m 延迟在您的应用程序中很重要，那么您最好使用 ADO.NET。但 EF 与 ADO.NET 相比还有许多其他优势