entity-framework - 如何解决使用 TPH 和复杂类型的初始非常慢的 EF 实体调用？

Question

我正在使用 EF6

我有一个通用表，它使用“每个层次结构表”方法保存不同类型的类对象的数据。此外，这些类对象使用复杂类型来定义其属性的类型。

所以使用一个虚构的例子，

表=人

“Mike the Teacher”是 Person 的“Teacher”实例，其 personType 为“Teacher”

“Teacher”实例有 2 个属性:complextypePersonalDetails 和complextypeAddress。

complextypePersonalDetails 包含 名字、姓氏和年龄。

complextype地址包含 房屋名称、街道、城镇、城市、县。

我承认这个设计可能有点过头了，问题可能是我造成的，但除此之外，我想在重写之前检查一下是否可以用 EF6 做更多的事情。

我正在使用 JetBrains DotTrace 对代码进行性能分析。

第一次打电话时，请说 personTeacher = db.person.OfType().First()

我得到了大约 150,000 毫秒的巨大延迟

周围:

     SerializedGeneratedViewOfType (150,000ms)
          TryGenerateQueryViewOfType
               GenerateTypeSpecificQueryView
                    GenerateQueryViewForSingleExtent
                        GenerateQueryViewForExtentAndType
                           GenerateViewsForExtentAndType
                              GenerateViewComponents
                                 EnsureExtentIsFullyMapped (90,000ms)
                                 GenerateCaseStatements    (60,000ms)

我使用创建 SQL 的“InteractivePreGenerateViews”nuget 包创建了一个预生成的 View 。然而即便如此，我仍然需要遭受第一次打击。此外，每次重新启动网络服务器/网站/应用程序池时，似乎都会发生这种情况。

我不完全确定 EF 过程，但我猜想在 Web 应用程序启动时会发生某种进一步形式的运行时编译或缓存。这种情况可能在哪里发生，是否有一种主动方法可以用来预生成/预编译/预缓存这个问题。

从中期来看，我们将在 Dapper 或 EF.Core 中重写此代码。那么现在，您有什么想法可以做什么吗？

谢谢。

Answer 1

我之前对此发表过评论，但后来撤回了，只是同意“这个设计可能有点过分，问题可能是我造成的”，但我想我会看看是否还有其他人加入。

初始启动成本是由于 EF 需要解析您的架构的映射。这种情况发生一次，即第一次访问上下文中的 DBSet 时。您可以通过在应用程序启动时执行查询来缓解这种情况，即

void Application_Start(object sender, EventArgs e)
{
  // Initialization stuff...

  using (var context = new MyContext())
  {
     var result = context.MyTable.Any(); // Spin up will happen here, not when the first user attempts to access a query.
  }
}

您实际上需要对 DbContext 运行查询来解析映射，仅新建一个是不够的。

对于更大或更复杂的模式，您还可以考虑利用有界上下文，其中每个上下文为应用程序的特定区域映射一组特定的关系。上下文越不复杂/全面，初始化就越快。

就设计而言，TPH 用于表示继承，这是您需要在相似实体之间建立“is-a”关系的地方。关系模型和 ORM 根据定义可以支持这一点，但它们更适合“has-a”关系。与其使用“是一个有地址的人”的模型，不如将关系最好地映射为一个人可能“有一个”地址。我曾开发过一个由工程师团队设计的系统，其中具有动态规则的整个报告系统由 6 个表表示。老实说，这些设计维护起来简直是一场噩梦。