9

我正在使用带有 DbContext 的 Database First 从 Linq-to-SQL 迁移到 Entity Framework (4.4)。我想知道以下行为是否正常：

using (var e = new AgendaEntities()) {
    var store = e.Stores.First();
    var office = e.Offices.Create();
    office.Store = store; // Set association
    Console.WriteLine(office.StoreID); // shows Guid.Empty, expected store.ID!
}

在 L2S 中，设置与Store实体的关联也会更新StoreID密钥。在 EF 中，这似乎没有发生。这与实体是新的还是从上下文加载的无关。

当 I 时SaveChanges，它会正确保存并StoreID更新为 match office.ID，但为什么这只会在保存后发生？

有什么我遗漏的，还是我现在应该手动保持外键同步？

解决方案编辑： 这称为属性修复，过去由生成的代理自动完成。但是，DbContext情况不再如此。根据这个 Connect issue，这是设计使然。

您好，DbContext 模板实际上不会生成将用作更改跟踪代理的类 - 只是延迟加载代理（不进行修复）。我们做出这个决定是因为变更跟踪代理很复杂，并且有很多细微差别，可能会让开发人员感到非常困惑。如果您希望在 SaveChanges 之前进行修复，您可以调用 myContext.ChangeTracker.DetectChanges。~EF 团队

另一种方法是调用DbContext.Entry(entity)，它将同步实体。这在本文中进行了描述：“同步 FK 和导航属性之间的更改”下的关系和导航属性

4

1 回答 1

6

不，实体框架会为你做这件事。阅读关系和导航属性以获取更多信息。

通过将新对象分配给导航属性。以下代码在课程和department. 如果对象附加到上下文，course则也将添加到department.Courses集合中，并且课程对象上的相应外键属性设置为 的键属性值department。

  • course.Department = department;

但正如您所观察到的，这只发生在您调用SaveChanges或上面链接文档的“同步 FK 和导航属性之间的更改”部分中提到的其他操作之一之后。

如果您使用没有代理的 POCO 实体，则必须确保调用 DetectChanges 方法以同步上下文中的相关对象。请注意，以下 API 会自动触发 DetectChanges 调用。

  • 数据库集.Add
  • 数据库集.查找
  • DbSet.Remove
  • DbSet.Local
  • DbContext.SaveChanges
  • DbSet.Attach
  • DbContext.GetValidationErrors
  • DbContext.Entry
  • DbChangeTracker.Entries
  • 对 DbSet 执行 LINQ 查询

如果这根本没有发生，我的猜测是您没有正确定义StoreID为导航属性的外键Store。

于 2013-03-21T17:05:24.133 回答