C#数据库访问:DBNull vs null

我们在这里使用自己的ORM,并为所有db表提供强类型包装器.我们还允许执行弱类型的临时SQL,但是这些查询仍然通过相同的类来从数据读取器中获取值.

在调整该类以使用Oracle时,我们遇到了一个有趣的问题.使用DBNull.Value或null是否更好？使用DBNull.Value有什么好处吗？使用null似乎更"正确",因为我们已经将自己从数据库世界中分离出来了,但是有一些含义(ToString()例如,当一个值为null时,你不能盲目地这样做)所以它肯定是我们需要有意识的东西决定.

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

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

通常,检查引用类型以确保它们不为空是一种很好的做法.您将检查除DB数据之外的其他内容的null,并且我发现最好保持整个系统的一致性,并使用null,而不是DBNull.

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

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