我得到这个错误时，我GetById()在一个实体，然后设置子实体的集合到我的新列表，来自MVC视图。
操作失败 关系是无法改变的 因为一个或多个外键 Properties是非空的。当一个 关系发生了变化 相关外键属性设置为 空值。如果外键是 不支持空值，新建 关系必须被定义 必须分配外键属性 另一个非空值或 必须删除不相关的对象。
我不太理解这句话:
这种关系无法改变 因为一个或多个外键 Properties是非空的。
我为什么要改变两个实体之间的关系?它应该在整个应用程序的生命周期内保持不变。
发生异常的代码只是简单地将集合中修改过的子类分配给现有的父类。这将有望满足取消子类，增加新的和修改。我本以为实体框架处理这个。
代码行可以提炼为:
var thisParent = _repo.GetById(1);
thisParent.ChildItems = modifiedParent.ChildItems();
_repo.Save();
当前回答
我有同样的问题，当我试图修改目标实体的标量属性，并意识到我不小心引用了目标实体的父:
entity.GetDbContextFromEntity().Entry(entity).Reference(i => i.ParentEntity).Query().Where(p => p.ID == 1).Load();
只是一个建议，确保目标实体不引用任何父对象。
其他回答
我有同样的问题，当我试图修改目标实体的标量属性，并意识到我不小心引用了目标实体的父:
entity.GetDbContextFromEntity().Entry(entity).Reference(i => i.ParentEntity).Query().Where(p => p.ID == 1).Load();
只是一个建议，确保目标实体不引用任何父对象。
这是因为子实体被标记为Modified而不是Deleted。
当执行parent. remove (Child)时，EF对子实体所做的修改只是将其父实体的引用设置为null。
当异常发生时，在执行SaveChanges()后，你可以通过在Visual Studio的即时窗口中输入以下代码来检查子对象的EntityState:
_context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Modified).ElementAt(X).Entity
其中X应替换为删除的实体。
如果你不能访问ObjectContext来执行_context.ChildEntity.Remove(child)，你可以通过使外键成为子表中主键的一部分来解决这个问题。
Parent
________________
| PK IdParent |
| Name |
|________________|
Child
________________
| PK IdChild |
| PK,FK IdParent |
| Name |
|________________|
这样，如果你执行parent.Remove(child)， EF将正确地将实体标记为已删除。
我不知道为什么其他两个答案这么受欢迎!
我相信您认为ORM框架应该处理它是正确的——毕竟，这是它承诺交付的。否则，您的域模型就会被持久性问题所破坏。如果你正确地设置了级联设置，NHibernate就能很好地管理它。在实体框架中也有可能，他们只是希望你在建立数据库模型时遵循更好的标准，特别是当他们不得不推断应该做什么级联时:
您必须使用“识别关系”来正确地定义父-子关系。
如果你这样做，实体框架知道子对象是由父对象标识的，因此它必须是一个“级联删除孤儿”的情况。
除了上面的，你可能需要(从NHibernate的经验)
thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);
而不是完全替换列表。
更新
@Slauma的评论提醒我，分离实体是整体问题的另一部分。为了解决这个问题，您可以采用使用自定义模型绑定器的方法，通过尝试从上下文加载模型来构造模型。这篇博客文章展示了我的意思。
我也遇到了同样的问题，但我知道它在其他情况下也能正常工作，所以我把问题简化为:
parent.OtherRelatedItems.Clear(); //this worked OK on SaveChanges() - items were being deleted from DB
parent.ProblematicItems.Clear(); // this was causing the mentioned exception on SaveChanges()
OtherRelatedItems有一个复合主键(parentId +一些本地列)，工作正常 probleaticitems有自己的单列主键，而parentId只是一个FK。这导致了Clear()之后的异常。
我所要做的就是使ParentId成为复合PK的一部分，以表明没有父元素就不能存在子元素。我使用DB-first模型，添加PK并将parentId列标记为EntityKey(因此，我必须在DB和EF中更新它-不确定EF单独是否足够)。
仔细想想，这是一个非常优雅的区别，EF使用它来决定没有父对象的子对象是否“有意义”(在这种情况下，Clear()不会删除它们并抛出异常，除非你将ParentId设置为其他/特殊的对象)，或者-就像最初的问题一样-我们期望项一旦从父对象中删除就会删除。
您之所以会遇到这种情况，是因为组合和聚合之间存在差异。
在复合中，创建父对象时创建子对象，销毁父对象时销毁子对象。所以它的生命周期是由父节点控制的。例:一篇博客文章及其评论。如果一个帖子被删除，它的评论也应该被删除。对一篇不存在的文章发表评论是没有意义的。订单和订单项目也是如此。
在聚合中，子对象可以不考虑父对象而存在。如果父对象被销毁，子对象仍然可以存在，因为以后它可能被添加到不同的父对象。例如:播放列表和该播放列表中的歌曲之间的关系。如果播放列表被删除，歌曲不应该被删除。它们可能被添加到不同的播放列表中。
实体框架区分聚合和组合关系的方式如下:
对于复合:它期望子对象有一个复合主键(ParentID, ChildID)。这是通过设计来实现的，因为孩子的id应该在他们父母的范围内。 对于聚合:它期望子对象中的外键属性为空。
So, the reason you're having this issue is because of how you've set your primary key in your child table. It should be composite, but it's not. So, Entity Framework sees this association as aggregation, which means, when you remove or clear the child objects, it's not going to delete the child records. It'll simply remove the association and sets the corresponding foreign key column to NULL (so those child records can later be associated with a different parent). Since your column does not allow NULL, you get the exception you mentioned.
解决方案:
1-如果你有强烈的理由不想使用复合键，你需要显式地删除子对象。这可以比之前建议的解决方案更简单:
context.Children.RemoveRange(parent.Children);
2-否则，通过在你的子表上设置正确的主键，你的代码看起来会更有意义:
parent.Children.Clear();
