用于大量表的实体框架4.1715

问题描述

| 我正在为具有700多个表的数据库开发数据访问层。我创建了包括所有表的模型，这产生了一个巨大的模型。然后，我将模型从4.1开始更改为使用DBContext，这似乎改善了其编译和工作方式。设计师似乎根本没有工作。 然后，我创建了一个测试应用程序，该应用程序仅将两个记录添加到表中，但是处理器在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的情况下在代码中定义映射时的实体框架。     ,        看一下这篇文章。 http://blogs.msdn.com/b/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-1.aspx