0

所以这个问题可能听起来有点深奥，但我注意到一些“神奇”的东西，我担心引擎盖下发生的事情的表现。假设我使用 TPC 设计创建实体，所有实体（直接或间接）从根基础实体继承，并且根基础实体包含在保存之前在代码中生成的全局唯一标识符（例如 Guid）（即，不是由数据库生成）。

我希望以下代码能够通过查询与对应的泛型类型相关的表来返回一个类型化的动态代理（它确实如此）：

context.Set<ConcreteDerivedEntityClass>().Find(someGuid)

但是，我也注意到我可以执行以下操作：

context.Set<BaseEntityClass>().Find(someGuid)

这非常酷，并且会神奇地为正确的具体类的请求 ID 返回一个类型化的动态代理。EF 到底如何知道 Id 属于哪个派生类/表？它是否会查看它知道的每个表/实体类型，直到找到匹配项（因此存在性能问题）？

4

1 回答 1

0

继承表/实体的主键也是指向基表的外键。

然后它需要做的就是查看从基类继承的类。它也可能在加载时将关系缓存在内存中的某个地方，以避免每次调用反射对性能的影响，因为关系是运行时静态的。

剩下的就是查询与子类名称匹配的表。由于需要继承，这将是一个聚集索引搜索。因此，虽然存在性能损失，但考虑到您获得的抽象，它是微不足道的。

编辑：

默认情况下，代码首先使用每个层次结构的表 (TPH)，它是 1 个非规范化表，其中将实体类型编码到Descriminator列中。在这种情况下，该列告诉 EF 要将结果类型转换为哪个实体。

上面提到的 TPC 需要在 DBContext 中添加一个额外的代码来指定正确的表映射。它可能会将其缓存在内存中，并运行上面已经描述的例程。

于 2013-10-25T19:18:08.877 回答