实体框架是否适用于更大的数据库？

Question

我使用Entity框架和一个包含大约50个表的数据库，它运行得很好。

但是，只是为了看看大型数据库在表/实体数量方面会发生什么，我试图将实体框架实现到拥有大约100多个表的数据库。 一旦我选择了所有表并点击了Entity Framework Wizard上的Finish按钮，它就挂了我的VS 2010，所以我无法得到任何结果。

我的问题如下;

1.如果我如上所述在表/主题方面拥有更大的数据库，那么使用实体框架是否是一个好主意？

2.使用Entity Framework处理数据库会有什么更好的方法？

3.我应该创建多个具有较少entite的DataContext或EDMX文件吗？

4.这些不同的DataContext如何相互影响？

5.在使用Entity Framework时，是否有任何建议的表格应该使用？

Answer 1

@Will是正确的，你所看到的限制是在设计师中，但它不是唯一的，所以Code-First不一定能解决问题。

如果设计师看起来很慢，那就不方便了，但不是世界末日。 Runtime performance considerations完全是另一回事。对于性能关键任务和调优，您需要understand the whole pipeline。

查看生成，例如，需要时间。您可以通过手动工作将其移动到编译时。

  

1.如果我如上所述在表/主题方面拥有更大的数据库，那么使用实体框架是否是一个好主意？

我当然不会让它阻止你。

  

2.使用Entity Framework处理数据库会有什么更好的方法？   3.我应该创建多个具有较少entite的DataContext或EDMX文件吗？

对于许多应用来说，这当然是一种很好的方法。

  

4.这些不同的DataContext如何相互影响？

绝大多数都没有。 A single, giant data model is often a bad idea由于服务耦合。但是，您可以通过EDMX中的包含或代码优先的类共享部分模型来选择性地耦合它们。

5.在使用Entity Framework时，是否有任何建议的表格应该使用？

一种方法是使用较小的模型，如您所建议的那样。另一种方法是解决运行时性能问题，有时带有更大的模型（参见上面给出的链接）。与任何潜在的性能“问题”一样，首先编写正确的代码，然后分析并修复慢速部分。通常，查询调优无论如何都比模型大小更重要。

Answer 2

EF，可能是的。 Visual Studio中的工具集？显然，并非如此。对于这么大的数据库，您可能想要Code First.

Answer 3

我认为EF本身对表的数量没有性能限制，但是对于特定表中的记录计数。您必须执行手动object-db关系（即表和对应属性的手动写入类），以避免VS10中的设计问题。 这在Hibernate中是明确的方法，但在EF可能不是。

Answer 4

实体框架是开发数据库应用程序的最佳方式。 我曾经使用LINQ to SQL开发我的应用程序，但由于Microsoft将来不会支持它，因此建议使用Entity Framework。 顺便说一下，.NET 4中的Entity Framework 4比以前的版本具有更好的性能。 我目前正在使用Entity Framework开发企业应用程序，它支持我的所有需求。 我建议使用实体框架。