具有可选要求的EF Code First + Fluent关系的多重约束违规？

出于某种原因，我让我在EF 6项目上做了一段时间，我会尽量避免命名外键。 我定义了大部分模型而没有逐步测试它，因此我遇到了多样性和不完整的Fluent API定义问题：

来自’User_InternalAuth’AssociationSet的关系处于’已删除’状态。 给定多重约束，相应的’User_InternalAuth_Target’也必须处于’已删除’状态。

在一种情况下，这是代码：

nModelBuilder.Entity() .HasOptional(u => u.InternalAuth) .WithRequired(a => a.User) .WillCascadeOnDelete(true); 

我的理解是它说：

• 实体User
• 具有InternalAuth类型的可选属性InternalAuth
• 另一方面， InternalAuth有一个必需的属性User ，所以所有的 InternalAuth都有User但是User可能有也可能没有`InternalAuth。
• 如果User被删除，那么他的InternalAuth也会被删除（这是否会覆盖处理像nullables这样的选项的可选行为？）

但是当我尝试删除User我收到一个关于InternalAuth和User之间某种关联的多样性的例外。

1. 如果EF了解关系的多样性，它是否有一种方法可以为它提供一个唯一的列名，那么有一个规范的命名约定？

2. 如果是这样，您是否真的需要通过注释模型或通过Fluent API明确定义外键？

3. 如果没有，我应该继续努力避免它，这是值得的还是可取的？ （我正在考虑迁移数据模型，数据库管理，任何EF怪癖）

4. 为什么尝试删除上述关系会违反多重约束？ 还需要知道什么？

Answer 1

假如说

您可以使用WillCascadeOnDelete方法在关系上配置级联删除。 如果依赖实体上的外键不可为空，则Code First会在关系上设置级联删除。 如果依赖实体上的外键可以为空，则Code First不会在关系上设置级联删除，并且当删除主体时，外键将设置为null。

我的猜测如下：FK可以为空，因此将其设置为null并具有所需约束的事实会导致exception的上升。

一种解决方案是将FK放入PK中，即在InternalAuth中将FK添加到PK中的用户。 执行此操作会在将PK的一部分设置为null时将实体标记为已删除。