c# - 在使用 int 对象 ID 时，我应该使用可为 null 的 int 吗？

Question

如果我在我的代码中使用一个类型为 int 的 BookID，它对应于数据库表中的一个 int 主键字段(我使用的是 C# 和 SQL Server)...这是最佳实践吗，当我在我的代码中传递 ID 时，使用可为 null 的 int 并检查 null 以查看 BookID 是否存在:

if (BookID != null) {

或者，分配一个不能与数据库中的实际值相对应的整数值(例如 0 或 -1)是否更好:

if (BookID > 0) {

---

编辑:为了进一步说明，假设我只想返回书的 ID，而不是整个书对象。在数据库中，主键不可为空，但是如果我要对不存在的“我的书名”的 BookID 执行查询，那么我将得不到任何结果。这应该反射(reflect)为 null 吗？

例子:

BookID = GetBookID("my book title");

Answer 1

如果你在数据库中有一个允许空的值，你应该使用Nullable<T>并避免引入 Magic Numbers .但是如果 BookId是(主)键，它可能不能为空(除了它用作外键)。

更新

对于查询数据库没有找到匹配记录这一点，有几种解决方案。我更喜欢抛出异常，因为如果应用程序试图获取不存在的记录，这通常表示错误。

Book book = Book.GetById(id);

在这种情况下，如果返回值为 null，您会怎么做？可能这一行之后的代码想要对这本书做一些事情，在 null 的情况下，该方法通常什么都不做

1. 抛出一个可以在 GetById() 中更好地完成的异常(除了调用者可能有更多关于异常的上下文信息)
2. 立即返回 null 或需要调用者处理的错误代码，但这实际上是在重新发明异常处理系统

如果绝对有效，找不到匹配的记录，我建议使用TryGet模式。

Book book;
if (Book.TryGetById(out book))
{
    DoStuffWith(book);
}
else
{
    DoStuffWithoutBook();
}

我相信这比返回 null 更好，因为 null 是一种神奇的值，我不喜欢在其中看到实现细节(引用类型或可空值类型可以采用名为 null 的特殊值)业务逻辑。缺点是你失去了可组合性——你不能再写 Book.GetById(id).Order(100, supplier) .

以下为您提供了可组合性，但有一个非常大的问题 - 这本书可能会在调用 Exists() 之间被删除。和 GetById() ，因此我强烈建议不要使用这种模式。

if (Book.Exists(id))
{
    Book book = Book.GetById(id).Order(100, supplier);
}
else
{
    DoStuffWithoutBook();
}