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

【问题标题】：Multiplicity constraint violations with optional-required EF Code First + Fluent relationship?具有可选要求的 EF Code First + Fluent 关系的多重性约束违规？
【发布时间】：2013-12-20 13:12:30
【问题描述】：

出于某种原因，我在 EF 6 项目上下定了决心，我会尽量避免命名外键。我在没有增量测试的情况下定义了大部分模型，因此我遇到了多重和不完整的 Fluent API 定义问题：

“User_InternalAuth”关联集中的关系位于 “已删除”状态。给定多重约束，对应的 “User_InternalAuth_Target”也必须处于“已删除”状态。

在一种情况下，代码如下：

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

我的理解是它在说：

实体User
具有InternalAuth 类型的可选属性InternalAuth
在另一端，InternalAuth 有一个必需的属性 User，因此所有 InternalAuths 有 Users 但Users 可能有也可能没有`内部验证。
如果User 被删除，他的InternalAuth 也会被删除（如果他有一个）（这是否会覆盖将可选项视为可空对象的可选行为？）

但是，当我尝试删除 User 时，我收到关于 InternalAuth 和 User 之间某些关联多重性的异常。

如果 EF 了解关系的多重性，是否有办法为其提供唯一的列名，从而有规范的命名约定？
如果是这样，您是否真的需要通过注释模型或通过 Fluent API 显式定义外键？
如果不是，我应该继续努力避免它是否值得或可取？（我正在考虑迁移数据模型、数据库管理、任何 EF 怪癖）
为什么尝试删除上述关系会违反多重性约束？它还需要知道什么？

【问题讨论】：

标签： c# entity-framework foreign-keys fluent fluent-interface

【解决方案1】：

假设

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

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

一种解决方案是将FK放在PK中，即在InternalAuth中将FK添加到PK中的User。这样做会将实体的一部分 PK 设置为 null 时将其标记为已删除。

【讨论】：