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

Question

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

  

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

在一个案例中，这是代码：

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

我的理解是它说：

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

但是，当我尝试删除User时，我会收到有关InternalAuth和User之间某种关联的多重性的例外情况。

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

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

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

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

Answer 1

假设

  

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

我的猜测如下：FK可以为空，因此使用所需约束将其设置为null会导致异常上升。

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