实体框架是否适用于具有 800 多个表的大型数据库？答案

【问题标题】：Does Entity Framework work well for large db with 800+ tables?实体框架是否适用于具有 800 多个表的大型数据库？
【发布时间】：2013-01-22 11:14:18
【问题描述】：

我的数据库中有 869 个表。我应该使用实体框架（版本 4）还是普通的旧 ADO.NET？

我对采用哪种方式持观望态度——EF（版本 4）或普通的旧 ADO.NET，对实体框架有轻微的倾向。我只担心实体框架模型设计器是否会在这么大的数据模型上冻结，以及维护它是否会是一场噩梦。

你们中的任何人都尝试过使用实体框架来处理如此庞大的数据集吗？

【问题讨论】：

标签： entity-framework entity-framework-4

【解决方案1】：

数据库中表的数量并不会真正影响数据访问层框架的选择。

EF 擅长它所做的事情，使用 EF 将导致比 ADO.NET 中的等效代码少得多。

因此，我几乎总是推荐 EF 而不是 ADO.NET。

【讨论】：

我同意你关于 EF 很好的观点。我已经使用 EF 2 年多了。不过，我从来没有在这么大的数据库中使用过它，所以我很想知道是否有人使用过。
好的，很好。你有什么顾虑？如果关系难以建模，我可以理解，但如果有 20 个表，您可能会遇到这个问题，我不认为这是一个表编号问题。

【解决方案2】：

这是基于经验的。我们是在线博彩公司，因此我们的数据传输涉及实时交付。我们做了一些基准测试，比较了使用 EF 和 ADO.NET 的查询速度，我们发现 ADO.NET 几乎比 EF 快 4 倍。如果您的表具有一对多的关系或具有复杂的关系，那么您的应用程序使用 EF 会更加繁重。为什么？因为如果您使用 EF 进行查询，它不仅会从主表中获取数据，还会从子表中获取记录。除非您使用 LINQ 查询中的“投影”以某种方式使您的对象更轻。

最后，您应该考虑一件事何时不使用 EF。

*如果您的首要任务是尽快交付或插入数据，请不要使用 EF。

【讨论】：

【解决方案3】：

对于 EF4 和 EF5 有这么多表，如果您遇到启动缓慢的问题，您可能需要使用预生成的视图。您可能想看看performance considerations - 这些是 EF5 特定的，但很多信息仍然适用于 EF4，或者至少应该让您了解需要注意哪些方面。如果可能，请使用 .NET Framework 4.5 - 此版本中有 significant performance 改进。

【讨论】：