C# 数据库访问：DBNull 与 null
我们在这里使用自己的 ORM，并为所有数据库表提供强类型包装器。 我们还允许执行弱类型的即席 SQL，但这些查询仍然通过同一类从数据读取器中获取值。
在调整该类以与 Oracle 一起使用时，我们遇到了一个有趣的问题。 使用 DBNull.Value 还是 null 更好？ 使用 DBNull.Value 有什么好处吗？ 使用 null 似乎更“正确”，因为我们已经将自己与数据库世界分开，但也有一些影响（例如，当值为 null 时，您不能盲目地使用 ToString() ）所以这绝对是我们需要做出有意识的决定的事情。
We have our own ORM we use here, and provide strongly typed wrappers for all of our db tables. We also allow weakly typed ad-hoc SQL to be executed, but these queries still go through the same class for getting values out of a data reader.
In tweaking that class to work with Oracle, we've come across an interesting question. Is it better to use DBNull.Value, or null? Are there any benefits to using DBNull.Value? It seems more "correct" to use null, since we've separated ourselves from the DB world, but there are implications (you can't just blindly ToString() when a value is null for example) so its definitely something we need to make a conscious decision about.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我发现使用 null 比 DB null 更好。
原因是，正如您所说，您正在将自己与数据库世界分开。
检查引用类型以确保它们不为空通常是一种很好的做法。 您将检查数据库数据以外的内容是否为 null，我发现最好保持整个系统的一致性，并使用 null，而不是
DBNull。从长远来看，从架构上来说，我发现它是更好的解决方案。
I find it better to use null, instead of DB null.
The reason is because, as you said, you're separating yourself from the DB world.
It is generally good practice to check reference types to ensure they aren't null anyway. You're going to be checking for null for things other than DB data, and I find it is best to keep consistency across the system, and use null, not
DBNull.In the long run, architecturally I find it to be the better solution.
如果您编写了自己的 ORM，那么我会说只使用 null，因为您可以随心所欲地使用它。 我相信 DBNull 最初只是用来解决值类型（int、DateTime 等）不能为 null 的事实，因此不要返回一些值，例如零或 DateTime.Min，这会暗示 null（坏，坏），他们创建了 DBNull 来表明这一点。 也许还有更多原因，但我一直认为这就是原因。 然而，现在 C# 3.0 中已经有了可为 null 的类型，因此不再需要 DBNull。 事实上，LINQ to SQL 只是到处使用 null。 完全没问题。 拥抱未来...使用 null。 ;-)
If you've written your own ORM, then I would say just use null, since you can use it however you want. I believe DBNull was originally used only to get around the fact that value types (int, DateTime, etc.) could not be null, so rather than return some value like zero or DateTime.Min, which would imply a null (bad, bad), they created DBNull to indicate this. Maybe there was more to it, but I always assumed that was the reason. However, now that we have nullable types in C# 3.0, DBNull is no longer necessary. In fact, LINQ to SQL just uses null all over the place. No problem at all. Embrace the future... use null. ;-)
根据我的经验，.NET DataTables 和 TableAdapters 与 DBNull 配合使用效果更好。 它还在强类型时打开一些特殊方法，例如就位时的 DataRow.IsFirstNameNull。
我希望我能给你一个更好的技术答案，但对我来说，底线是在处理数据库相关对象时使用 DBNull，然后在处理对象和 .NET 相关代码时使用“标准”null。
From the experience I've had, the .NET DataTables and TableAdapters work better with DBNull. It also opens up a few special methods when strongly typed, such as DataRow.IsFirstNameNull when in place.
I wish I could give you a better technical answer than that, but for me the bottom line is use DBNull when working with the database related objects and then use a "standard" null when I'm dealing with objects and .NET related code.
使用
DBNull。我们在使用 null 时遇到了一些问题。
如果我没记错的话，您不能将空值插入字段，只能使用 DBNull。
可能只是与 Oracle 有关，抱歉，我不知道详细信息了。
Use
DBNull.We encouintered some sort of problems when using null.
If I recall correctly you cannot INSERT a null value to a field, only DBNull.
Could be Oracle related only, sorry, I do not know the details anymore.