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

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

解决方案

回答

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

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

回答

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

回答

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

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

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

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

回答

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