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

Question

我使用Entity框架和一个有大约50个表的数据库,它工作得很好.

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

我的问题如下;

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

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

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

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

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

Answer 1

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

如果设计师看起来很慢,那就不方便了,但不是世界末日.运行时性能考虑是另一回事.对于性能关键任务和调优,您需要了解整个管道.

视图生成,例如,需要时间.您可以通过手动工作将其移动到编译时.

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

我当然不会让它阻止你.

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

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

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

绝大多数没有.由于服务耦合,单个巨型数据模型通常是个坏主意.但是,您可以通过EDMX中的包含或代码优先的类共享部分模型来选择性地耦合它们.

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

一种方法是使用较小的模型,如您所建议的那样.另一种方法是解决运行时性能问题,有时会出现更大的模型(请参阅上面给出的链接).像任何潜在的性能"问题"一样,首先编写正确的代码,然后分析并修复慢速部分.通常,查询调优无论如何都比模型大小更重要.