227 Mapped 类的子类型导致Entity framework 数据库上下文初始化缓慢?
Posted
技术标签:
【中文标题】227 Mapped 类的子类型导致Entity framework 数据库上下文初始化缓慢?【英文标题】:227 subtypes of Mapped class causes slow Entity framework database context initialisation? 【发布时间】:2014-08-24 06:19:45 【问题描述】:我有一个 Country 类,有 227 个子类型(每个 Country 一个)。 旧版限制使我无法轻松更改此设置。
我已经仔细检查过,事实上大量子类型导致 EF 的初始化速度非常慢,在第一次调用时,第一次访问 DbContext 大约需要 2 分钟!!
有什么办法可以在实体框架中保持如此多的子类型并避免这种缓慢的启动??
挂起可以通过对 Db.Users.Find(1) 进行简单调用来发生; (例如)
【问题讨论】:
【参考方案1】:伤害您的是 Entity Framework 在冷查询(a查询没有映射视图的实体。这些模型是从实体到表的映射,这使得 EF 之后变得如此高效:
根据规范计算这些视图的过程 映射就是我们所说的视图生成。视图生成可以 在加载模型时或在构建时动态发生,通过 使用“预先生成的视图”;后者以以下形式序列化 将实体 SQL 语句转换为 C# 或 VB 文件。
预生成视图是使用 VS 中的 EF 工具设计的,并且在编译时而不是在运行时构建。
您还可以考虑使用 Entity Framework Power Tools 通过右键单击生成 EDMX 和 Code First 模型的视图 模型类文件并使用实体框架菜单选择 “生成视图”。 Entity Framework Power Tools 仅适用于 DbContext 派生的上下文,可以在以下位置找到 http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d.
有关如何在实体上使用预生成视图的更多信息 框架6访问http://msdn.microsoft.com/en-us/data/dn469601。
检查这个Reference on Entity Framework View Generation
您需要了解的有关预生成视图、应用它们,甚至将它们移动到自己的程序集的所有信息(以便视图生成构建独立于应用程序发布构建。
【讨论】:
【参考方案2】:当您创建 Context 的第一个实例时, EF 验证数据库架构, 如果模型没有变化,可以通过静态构造器跳过这一步:
static ctor
Database.SetInitializer<BillingContext>(null);
【讨论】:
感谢您的提示,嗯,这似乎没有帮助。以上是关于227 Mapped 类的子类型导致Entity framework 数据库上下文初始化缓慢?的主要内容,如果未能解决你的问题,请参考以下文章
如何解决 Class xxx is not a valid entity or mapped super class 错误
错误笔记之Hibernate出现xxx is not mapped[from Xxx where ...]的原因排查
SetState Flutter 导致错误:“int”类型不是“String”类型的子类型