entity-framework - 用于大量表的 Entity Framework 4.1 (715)

Question

我正在为具有 700 多个表的数据库开发数据访问层。我创建了包含所有表格的模型，从而生成了一个巨大的模型。然后我将模型更改为使用 4.1 中的 DBContext，这似乎改进了它的编译和工作方式。设计师似乎根本没有工作。

然后我创建了一个测试应用程序，它只向表中添加了两条记录，但处理器在 db.SaveChanges 方法中达到了 100%。作为一个黑匣子，很难确定出了什么问题。

所以我的问题是

1. Is the entity framework the best approach to a large database
2. If so, should the model be broken down into logical areas. I did note that you cant have the same sql table in multiple models
3. I have read that the code only approach is best in these large cases. What is that.

任何指导将不胜感激

谢谢

Answer 1

大型数据库总是很特别。在使用大型数据库时，任何技术都有一些优点和缺点。

您遇到的问题很可能与构建模型有关。当您第一次启动应用程序并使用 EF 相关的东西时，EF 必须构建模型描述并编译它 - 这是您在 EF 中可以找到的最耗时的操作。此操作的复杂性随着模型中实体的数量而增加。编译模型后，它会在应用程序的整个生命周期中重复使用(如果重新启动应用程序或卸载应用程序域，则必须再次编译模型)。您可以通过预编译模型来避免这种情况。它在设计时完成，您使用一些工具从模型生成代码并将该代码包含到您的项目中(必须在模型中的每次更改后再次完成)。对于基于 EDMX 的模型，您可以使用 EdmGen.exe要生成 View 和基于代码的模型，您可以使用 EF Power Tools CTP1 .

EDMX(设计者)在 VS 2010 SP1 中得到了改进，能够处理大型模型，但我仍然认为这种情况下的大型模型大约是 100 个实体/表。同时，您很少需要同一模型中的 715 个表。我相信这 715 个表确实为多个域建模，因此您可以将它们划分为多个模型。

当您首先使用 DbContext 和代码时也是如此。如果你为一个类建模，当类公开 715 个属性时，你认为它是正确的设计吗？我不这么认为，但这正是您得出的 DbContext看起来像 - 它为每个公开的实体集都有一个公共(public)属性(在最简单的映射中，它意味着每个表一个属性)。

同一个实体可以在多个模型中使用，但您应该尽量避免使用它，因为在一种上下文类型中加载实体并在其他上下文类型中使用它时会引入一些复杂性。

当您在代码中定义映射而不使用 EDMX 时，仅代码 = 代码优先 = Entity Framework 。