关于orm：C#数据库访问：DBNull与null

C# Database Access: DBNull vs null

我们在这里使用自己的ORM，并为所有数据库表提供强类型package器。我们还允许执行弱类型的即席SQL，但是这些查询仍然要经过同一类才能从数据读取器中获取值。

在调整该类以使其与Oracle配合使用时，我们遇到了一个有趣的问题。使用DBNull.Value还是null更好？使用DBNull.Value有什么好处？使用null似乎更"正确"，因为我们已经将自己与数据库世界分开了，但是有一定的含义(例如，当一个值为null时，您不能盲目地ToString())，因此我们肯定需要这样做做出有意识的决定。

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

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

通常最好的做法是检查引用类型，以确保它们都不为空。您将要检查DB数据库数据以外的其他内容是否为null，我发现最好保持整个系统的一致性，并使用null，而不是DBNull。

从长远来看，从结构上看，我认为它是更好的解决方案。

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

根据我的经验，.NET DataTables和TableAdapters与DBNull更好地协同工作。在强类型化时，它还会打开一些特殊方法，例如在适当位置时使用DataRow.IsFirstNameNull。

希望我能给您一个更好的技术答案，但是对我来说，最重要的是在处理与数据库相关的对象时使用DBNull，然后在处理对象和.NET时使用"标准" null相关代码。

使用DBNull。
使用null时，我们会遇到一些问题。
如果我没记错的话，您不能将null值插入字段，而只能将DBNull插入。
只能与Oracle相关，对不起，我不再知道详??细信息。