实体框架和约束答案

【问题标题】：Entity Framework and constraints实体框架和约束
【发布时间】：2018-07-23 15:31:33
【问题描述】：

我想为 DB 编写约束。 IE。我的实体类有 2 个字段：

public int DriverCompensationTypeId { get; set; }
public decimal? CompensationRate { get; set; }

我想说明：

DriverCompensationTypeId 的唯一允许值是 0, 1, 2, 3
如果DriverCompensationTypeId == 0，CompensationRate 始终应为null，在所有其他情况下不应为null。

这些约束怎么写？

【问题讨论】：

您可以在模型中定义枚举并将属性类型设置为枚举
@FelixCastor 但对于第二种情况？
这是更多的业务逻辑，不应由您的数据库处理。
@FelixCastor 我想在 db 中有正确的数据。拒绝另一个数据库操作员写入无效数据
@OlegSh 我同意FelixCastor的观点，现在的写法，应该在业务层处理。另一种方法是将其设为外键并指向您的选项为 0,1,2,3 的另一个表，这将确保数据库中只有这些数字，因为插入其他任何内容都会导致异常

【解决方案1】：

提到的枚举 Felix Castor 是强制 DriverCompensationTypeId 的允许值为 0 到 3。它仍然存储为 int，这就是枚举的作用:)

使用 DriverCompensationTypeId 的属性设置器是通过代码将 CompensationRate 设置为 null 的一种方法。

(SQL Server) 创建添加/更新触发器以在存储数据之前验证和/或调整数据是另一回事。代码更改包括处理数据库错误。

将业务规则放在业务层而不是实体中是更好的方法。然后你可以在你的映射/验证代码中......

CompensationRate = DriverCompensationTypeId == 0 ? null, CompensationRate;

当然，如果您决定使用枚举，您可以用枚举值代替“0”

插件：在创建新实体/属性时，如何实现业务规则的灵活性要大得多。一旦属性（字段）存在，那么您会受到所涉及的工作量的更多限制。 “关注点分离”原则与like 非常相似（一个实体的数据访问与其他实体的数据访问）。

业务规则不应该关心数据的存储或访问方式或位置。如果您采用此原则/模式，那么您很可能希望将所有验证和业务逻辑组合到一个层中，我发现以后更容易定位和维护。

这并不意味着您不进行客户端验证，这有助于向用户提供即时快速反馈，而无需往返服务器。但是您总是必须进行服务器端验证以防止各种黑客攻击。 UI = 便利性，服务器 = 安全性/一致性。

【讨论】：