c# - C# 数据库访问：DBNull 与 null

Question

我们在这里使用自己的 ORM，并为我们所有的数据库表提供强类型包装器。我们还允许执行弱类型的 ad-hoc SQL，但这些查询仍然通过同一个类从数据读取器中获取值。

在调整该类以使用 Oracle 时，我们遇到了一个有趣的问题。使用 DBNull.Value 还是 null 更好？使用 DBNull.Value 有什么好处吗？使用 null 似乎更“正确”，因为我们已经将自己与 DB 世界分开了，但是有一些影响（例如，当值为 null 时，你不能盲目地ToString()）所以它绝对是我们需要意识到的关于的决定。

Answer 1

我发现使用 null 而不是 DB null 更好。

原因是，正如您所说，您将自己与数据库世界分开。

检查引用类型以确保它们不为空通常是一种好习惯。您将检查数据库数据以外的内容是否为 null，我发现最好在整个系统中保持一致性，并使用 null，而不是DBNull.

从长远来看，在架构上我发现它是更好的解决方案。

Answer 2

如果您已经编写了自己的 ORM，那么我会说只使用 null，因为您可以随心所欲地使用它。我相信 DBNull 最初仅用于解决值类型（int、DateTime 等）不能为null 的事实，而不是返回诸如零或 DateTime.Min 之类的值，这意味着null（坏、坏)，他们创建了 DBNull 来表明这一点。也许还有更多，但我一直认为这就是原因。但是，现在我们在 C# 3.0 中有了可为空的类型，不再需要 DBNull。事实上，LINQ to SQL 只是到处使用 null。完全没有问题。拥抱未来……使用 null。;-)

Answer 3

根据我的经验，.NET DataTables 和 TableAdapters 与 DBNull 一起工作得更好。它还在强类型时打开了一些特殊方法，例如 DataRow.IsFirstNameNull 到位时。

我希望我能给你一个比这更好的技术答案，但对我来说，底线是在处理与数据库相关的对象时使用 DBNull，然后在处理对象和 .NET 相关代码时使用“标准”空值。

Answer 4

使用DBNull.
我们在使用 null 时遇到了一些问题。
如果我没记错的话，您不能将空值插入到字段中，只能插入 DBNull。
可能只是 Oracle 相关的，抱歉，我不知道细节了。