只是想知道 DAL 是否有任何最佳实践来表示空值（来自可为空的列）。
我们目前有自己的内部 DAL，并用 int.MinValue 表示空值。但是，这种上升与开发人员有关，他们认为在比较值时，我们故意将另一个“附加”值强加到 int.MinValue 上，而 int.MinValue 用于 DAL 层中的空值这一事实令人困惑。所以其他人提出了 .net 2.0 的 NullValue，但我们发现这种方法也存在性能和语法问题：
那么，您对此有何看法？其他著名的 ORM 如何处理空值？是否有围绕这个问题的最佳实践？
为了表示一个可为空的整数，我每次都使用Nullable<int>(aka )。int?这正是它的设计目的。您提供了几个链接，但您能否准确说明可空类型的语法问题在哪里，以及您在哪里看到了重大的性能问题（请记住，数据库调用可能比任何转换都贵得多正在进行中）。
编辑：我注意到倒数第二个链接指向一个涉及我的新闻组对话。我在这种情况下避开可空类型的原因是因为问题是围绕可能需要将空值有效地传达给没有可空值类型的平台的 Web 服务。我认为这不适用于您所描述的情况。
添加为答案，因为评论太长了。
如果你必须在你的代码库中乱扔Nullable.Compare，那你就错了。你不应该比较两个Nullable<int>值，除非你已经知道它们都是非空的。
唯一的例外是在完全无法避免的地方，例如在聚合或排序时。如果您使用标准方法（例如 Linq）来执行此操作，则无需实现任何特殊的方法来处理此问题，因为Nullable<T>implements IComparable<T>.
有一个原因是，在 SQL Server 中，任何包含 NULL 术语的表达式的计算结果都是 NULL。如果表达式中的一个术语为 NULL，则表达式的结果是没有意义的 - 除非表达式明确指出（通过 ISNULL 或 COALESCE）如果术语为 NULL 该怎么办。这是一个应该在表达式内部或周围做出的决定，而不是全局的。
例如，考虑这个看似简单的逻辑：
if (qtyOrdered > qtyInStock)
{
Reorder(qtyInStock - qtyOrdered);
}
qtyInStock如果为null，那将引发异常。如果为空，这个逻辑应该做什么？qtyInStock我们不知道：这是一个必须在业务逻辑设计中解决的问题，而且还没有解决。
但是我们几乎可以肯定知道一件事：如果qtyInStock为空，则为项目生成新订单Int.MinValue - qtyOrdered是错误的答案。如果您使用幻数来指示空值，这就是这样的逻辑。逻辑被打破了，它需要被修复，而不是隐藏。
我使用可空类型，如 int? 等等。
感谢您的快速回复。
我们仍在决定使用哪一个，我不知道 nullable 最终会如何执行，但我同意数据库访问将成为瓶颈。
我看到使用 nullable 的问题实际上是由于此处概述的内置 .net 运算符下的不同行为。
如果我使用可为空的类型并且想要正确比较两个整数，我将不得不使用 Nullable.Compare 语法来乱扔我的代码库。我不确定这是否是最好的解决方案。
CJ Date 认为，在 RDBMS 上下文中不应存在空值，部分原因是这些问题。你如何避免它们？通过重新设计它们：以各种方式拆分数据，以便空列变得无关紧要，并在这种情况下从逻辑设计中删除。换句话说，重新设计您的表和列，以便每一列都被限制为NOT NULL但也具有有意义的值（没有替换自定义哨兵，如int.MinValue）。
这是很多工作，人们会很高兴地争论它是否值得，但如果你那么关心你的实现的性能和纯度，那么也许这就是你想要的。
在我的数据访问层中，它将 null 转换为对上下文有意义的值。我的 DAL 的目的是将数据与应用程序连接起来，因此 DAL 必须知道数据代表什么，然后设计人员才能推断出一个好的新值。也许零是空整数字段的正确答案，也许错误消息可能会出现在文本字段中。
这样，当我的应用程序读取数据时，它会获取数据，当它显示给最终用户时，他们会看到某些内容为零，并且文本应该显示“没有可用的文本”之类的东西。
使用整数？只是将空问题推高了一级，这就是我现在使用 DAL 的方式。