实体框架为不可为空的数字字段定义约束答案

【问题标题】：Entity Framework Defining constraints for Non-Nullable numeric fields实体框架为不可为空的数字字段定义约束
【发布时间】：2011-05-24 14:09:03
【问题描述】：

这是对这个问题的跟进
Entity Framework 4 not respecting database constraints for numeric fields

有没有可能实现如下

表：Foo
PkId - int、primary、autoincrement
Bar - int，允许 null=false，没有默认值

现在在生成 EF 模型时 'Bar' 字段是数据库正确定义为 Nullable=false, Type=Int32。

现在当我执行以下操作时

var foo = new Foo();
context.AddToFoos(foo);
context.SaveChanges();

该行被插入到数据库中，'Bar' 的值为 0？

我期望的是应用程序级别的异常，因为从技术上讲，应用程序并未设置 Bar。它的 .Net 默认值不会自动转换为特定数据库的有效值。

行为应该类似于数据库中的字符串列。字符串得到了正确处理，因为它们的状态为 null，而且翻译得很好。

对于数字列，这通常是如何实现的？

【问题讨论】：

标签： entity-framework-4

【解决方案1】：

当您不想存储 0 时，不要忘记在模型对象中设置 Bar 属性的值。当您创建新对象并调用 SaveChanges 时，INSERT 命令会发送到数据库其中包含映射到数据库表的 all 模型属性的值。类中的 int 属性始终有一个值，而您已将此值设置为 0 - 即通过调用对象的构造函数。

EF 不会只将对象的一半发送到数据库，这是 Object-Relational-Mapper 的基本点。当然，通过提交原始 SQL INSERT 命令，您只能设置表行列值的一半，如果您不为 Bar 列设置值，则会出现异常。但是，当您使用 ORM 时，您不会提交 INSERT 命令，而是存储新对象。

究竟是什么问题？如果没有 Bar 的值是有效的，则该列应该可以为空并且属性 int?。如果它必须有一个值而不是值 0，那么只需在对象的构造函数中将 Bar 设置为 1 或其他内容，或者在保存对象之前应用适当的验证。

在我看来，您想要的那种异常是不可能的，而且没有意义，因为在存储对象时 EF 将提交的 INSERT 命令中设置值是不可能的不

【讨论】：

谢谢，确定在代码中设置值没问题，但这不是问题。想象一个场景，有 20 多个不同的应用程序将数据写入数据库。 DB 约束表示“您必须为此列提供有效值”。让 ORM 尊重这个约束会很好，因为我不能保证每个应用程序都正确实现。这种类型的功能已经存在了 20 多年。如果该字段不脏，请不要将其写入数据库或抛出。不要只是将框架中的任意默认值写入数据库。
@bic：在 new 对象的所有属性都是脏的并且对于更新只有更改的列在更新命令中发送到 DB 的意义上，该约束得到尊重。约束检查的类型只是必要的，因为在关系数据库中，您可以在创建新行时设置单个列。在 ORM（以及 OO 数据库）中你不能，因此不需要约束检查。也许这是“对象关系阻抗不匹配”的一个例子：没有默认值的简单数据类型在“O”端不存在，就像在“R”端“没有默认”的列一样。
@bic：还有一点：考虑一下您与 POCO 合作。一个对象是在上下文之外“某处”创建的，例如在另一个程序集中，或者它甚至来自任何类型的远程服务，并且线路另一端的开发人员已明确将Bar 设置为 0，因为它是他想要存储的有效值。 EF 如何识别这是在对象构造函数中创建的“默认值”还是已在代码中明确设置？我想不通。这种检测是否明确设置了值是不可能的，至少对于 POCO 来说是这样。
@Slauma：“不存在没有默认值的简单数据类型”虽然这是真的，但令我惊讶的是 EF 不支持通过属性设置器跟踪更改。新对象的初始状态可能是“已添加”，但该属性尚未设置，不应包含在基础 DB 语句中。这似乎相对简单。私有成员 In32 被初始化但不是通过公共设置器。无论如何，感谢您的反馈。
@Slauma：将值显式设置为 0 不是问题。该应用程序已设置该值，这很好。问题不在于实际值（在本例中为 0），而是在数据库明确需要它时尚未设置。