的我正在开发超过700台用于数据库的数据访问层。我创建了包含所有表格的模型，这些模型生成了一个巨大的模型。然后，我改变了模型，使用4.1中的DBContext，这似乎改进了它的编译和工作方式。设计师似乎根本没有工作。实体框架4.1大量的表（715）
我然后创建该刚添加两个记录表中的测试应用程序，但该处理器在db.SaveChanges方法去100％。作为一个黑匣子，很难确定哪里出了问题。
所以我的问题是
- 是实体框架的大型数据库，最好的办法
- 如果是的话，应该在模型分解成逻辑区域。我没有注意，你不能有多种型号相同的SQL表
- 我看过的唯一代码方法最好在这些大的情况下。那是什么。
任何指导，将真正的赞赏
感谢
大型数据库总是很特别。任何技术在处理大型数据库时都有优点和缺点。
您遇到的问题是最可能与构建模型。当您启动应用程序并首次使用EF相关内容时，EF必须构建模型描述并进行编译 - 这是您在EF中可以找到的最耗时的操作。此操作的复杂性随着模型中实体的数量而增加。一旦模型编译完成，它将在应用程序的整个生命周期中重用（如果重启应用程序或卸载应用程序域，模型必须重新编译）。您可以通过预编译模型来避免这种情况。这是在设计时完成的，您使用某种工具从模型生成代码，并将该代码包含到项目中（每次在模型中进行更改后都必须重新执行）。对于基于EDMX的模型，您可以使用EdmGen.exe生成视图，对于代码优先的模型，您可以使用EF Power Tools CTP1。
EDMX（设计师）在VS 2010 SP1进行了改进能够与大型模型的工作，但我仍然认为在这种情况下，大的是100左右的实体/表。在同一时间，你很少需要在同一个模型中的715个表格。我相信这715个表格的确可以模拟多个领域，因此您可以将它们分成多个模型。
同样的，当您使用的DbContext和代码首先是真实的。如果你对一个类进行建模，你认为这个类是否暴露了715个属性是正确的设计？我不这么认为，但是这也正是你的派生DbContext样子 - 它为每个裸露实体集的公共属性（在最简单的映射它意味着每个表中的一个属性）。
同一个实体可以在多个机型上使用，但你应该尽量避免它尽可能多的，因为它可以在一个上下文类型加载实体和其他上下文类型使用它时，引入了一些复杂性。
代码仅=代码在定义在码映射，而不使用第一EDMX =实体框架。
除了什么@Ladislav建议，我觉得做EDMX模块的基础上，在这种情况下可能会有帮助，像管理员有单独的EDMX，购买模块另一EDMX同样，对于其他模块 – Deepesh 2011-05-31 11:08:14
我安装的是EF电源工具，并从现有数据库创建一个仅用于代码的模型。这当然似乎比EDMX更好。但是，我仍然存在添加记录将该程序发送到lala的问题。我怎样才能弄清楚什么是错误的？ – 2011-05-31 22:09:40
当您使用EF Migrations时，多个上下文会让您陷入麻烦，因为那需要一个数据库==一个上下文，是的？ – 2012-05-25 15:50:56