我正在为拥有700多个表的数据库开发数据访问层。我创建了包含所有表格的模型，这些表格生成了一个巨大的模型。然后我将模型更改为使用4.1中的DBContext，这似乎改进了它的编译和工作方式。设计师似乎根本没有工作。
然后我创建了一个测试应用程序，它只是向表中添加了两条记录，但处理器在db.SaveChanges方法中达到了100％。作为一个黑匣子，很难弄清楚出了什么问题。
所以我的问题是
- 实体框架是大型数据库的最佳方法吗
- 如果是这样，应该将模型分解为逻辑区域。我注意到你不能在多个模型中使用相同的sql表
- 我已经读到，在这些大型案例中，仅代码方法最佳。那是什么。
任何指导都会得到真正的赞赏
由于
答案 0 :(得分：12)
大型数据库总是很特别。使用大型数据库时，任何技术都有一些优点和缺点。
您遇到的问题很可能与构建模型有关。当您启动应用程序并首次使用EF相关内容时，EF必须构建模型描述并进行编译 - 这是您在EF中可以找到的最耗时的操作。此操作的复杂性随着模型中实体的数量而增加。编译模型后，它将在应用程序的整个生命周期内重用（如果重新启动应用程序或卸载应用程序域，则必须再次编译模型）。您可以通过预编译模型来避免这种情况。它是在设计时完成的，您可以使用某个工具从模型生成代码，并将该代码包含在项目中（必须在模型中的每次更改后再次执行）。对于基于EDMX的模型，您可以使用EdmGen.exe生成视图，也可以使用基于代码的模型EF Power Tools CTP1。
EDMX（设计师）在VS 2010 SP1中进行了改进，以便能够使用大型模型，但我仍然认为在这种情况下大的是大约100个实体/表。同时，您在同一型号中很少需要715个表。我相信这些715表确实模拟了几个域，因此您可以将它们分成多个模型。
首先使用DbContext和代码时也是如此。如果你为一个类建模，你认为当类暴露715属性时它是正确的设计吗？我不这么认为，但这正是你的派生DbContext看起来的样子 - 它为每个公开的实体集都有一个公共属性（在最简单的映射中它表示每个表有一个属性）。
可以在多个模型中使用相同的实体，但是您应该尽可能地避免它，因为在一个上下文类型中加载实体并在其他上下文类型中使用它时会引入一些复杂性。
仅代码=代码优先=在不使用EDMX的情况下在代码中定义映射时的实体框架。
答案 1 :(得分：2)