performance - 具有非常大且复杂的数据集的实体框架

Question

如果您能帮助我解决我的问题，我将不胜感激：

EF5 是否足够可靠和高效以处理现实世界中非常庞大和复杂的数据集？

将 EF5 与 ADO.NET 进行比较，EF5 是否需要显着更多的资源，例如内存？

对于那些在具有非常庞大和复杂数据集的真实项目中尝试 EF5 的人，您对目前的性能感到满意吗？

Answer 1

我在 EF 4.1 上对此进行了一些研究，尽管需要牢记对 EF5 的性能升级，但一些细节可能仍然适用。

ADO 与 EF 性能

我的结论：-您不会将 ADO 性能与必须从 C# 动态生成实际 SQL 语句并将该 sql 语句转换为强类型对象的框架相匹配，即使使用预编译和warmed' 声明（性能测试得出结论）。对于许多发现在 C# 中编写和维护 Linq 比存储过程和映射代码更容易的人来说，这是一个愉快的权衡。

- 您仍然可以使用性能与 ADO 相同的存储过程，这对我来说是完美的情况。您可以在它工作的情况下将 linq 写入 sql，并且一旦您想要更高的性能，就编写存储过程并将其导入 EF 以享受可能的最佳性能。

- 没有技术原因可以避免 EF 接受您的项目要求以及您的团队的知识和舒适度。一定要确保它适合您选择的设计模式.. EF Anti Patterns to avoid

我希望这有帮助。

Answer 2

由于 EF 创建了对数据访问的抽象。EF 的使用引入了许多额外的步骤来执行任何查询。但是有一些变通方法可以降低成本。由于 MS 正在推广这个 ORM，我相信他们也在为提高性能做了很多工作。EF 6 beta 已经发布。MSDN 上有一篇关于 EF5 性能的好文章。

http://msdn.microsoft.com/en-us/data/hh949853

如果在从 EF 查询填充 DBSet 后需要对 DBset 进行大量复杂的操作和迭代，我将不会使用 EF。

希望这可以帮助。

Answer 3

EF 不仅能够处理大量数据。就像在普通的 ADO.NET 中一样，您需要了解如何正确使用它。在 ADO.NET 中编写性能不佳的代码同样容易。同样重要的是要记住 EF 是建立在 ADO.NET 之上的。

与代码优先的 EF 方法相比，具有大量数据的 DBSet 会慢得多。如果操作正确，普通数据读取器可能会更快。

正确答案是“个人资料”。对一些大对象进行编码并分析差异。