但只是为了看看在表格/实体数量方面的大型数据库会发生什么,我试图将实体框架实现到拥有大约100个表的数据库.
一旦我选择了所有表并点击了Entity Framework Wizard上的Finish按钮,它就挂了我的VS 2010,所以我无法得到任何结果.
我的问题如下;
1.如果我在表/ Entites方面拥有更大的数据库,如上所述,使用实体框架是否是个好主意？
2.使用Entity Framework处理数据库的更好的方法是什么？
3.我应该创建多个具有较少entite的DataContext或EDMX文件？
4.这些不同的DataContext如何相互交互？
5.在使用Entity Framework时,是否有任何建议不应使用的表格？
解决方法
如果设计师看起来很慢,那就不方便了,但不是世界末日. Runtime performance considerations完全是另一回事.对于性能关键任务和调优,您需要understand the whole pipeline.
视图生成例如需要时间.您可以通过手动工作将其移动到编译时.
1.If I have larger Database in terms of Table/Entites as described above,Is it a good idea to use Entity Framework?
我当然不会让它阻止你.
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
对于许多应用来说,这当然是一种很好的方法.
4.How will these different DataContext interact with each other?
大部分都不是. A single,giant data model is often a bad idea由于服务耦合.但是,您可以通过在EDMX中包含部分模型或在代码优先中共享类来选择性地耦合它们.
5.在使用Entity Framework时,是否有任何建议不应使用的表格？
一种方法是使用较小的模型,如您所建议的那样.另一种方法是解决运行时性能问题,有时会出现更大的模型(参见上面给出的链接).像任何潜在的性能“问题”一样,首先编写正确的代码,然后分析并修复慢速部分.通常,查询调优无论如何都比模型大小更重要.
