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

Question

如果你能帮助我解决我的问题，我将非常感激：

EF5是否可靠且高效，足以应对现实世界中非常庞大和复杂的数据集？

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

对于那些在具有非常大且复杂的数据集的真实世界项目中尝试过EF5的人，您对目前的表现感到满意吗？

Answer 1

由于EF创建了数据访问的抽象。 EF的使用引入了许多执行任何查询的附加步骤。但是有一些降低成本的解决方法。由于MS正在推广这款ORM，我相信他们在提升性能方面做得也很多。 EF 6测试版已经发布。 有关MS5的性能的文章在MSDN上有用。

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

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

希望这有帮助。

Answer 2

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

对于大量数据，DBSets将比代码第一EF方法慢得多。如果正确完成，Plain Datareaders可能会更快。

正确答案是'个人资料'。编码一些大型对象并分析差异。

Answer 3

我在EF 4.1上对此进行了一些研究，虽然EF5的性能已经升级，但仍有一些细节可能仍然适用。

ADO vs EF performance

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

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

- 没有技术理由可以避免EF接受您的项目要求以及您的团队知识和舒适程度。请务必确保它符合您选择的设计模式。EF Anti Patterns to avoid

我希望这会有所帮助。