我们有自己的ORM我们在这里使用，并为我们所有的数据库表中提供强类型的包装。 我们还允许执行弱类型即席SQL，但这些查询仍通过相同的类获取值了数据读取的。
在调整该类与Oracle合作，我们已经遇到了一个有趣的问题。 它是更好地使用DBNull.Value，还是空？ 是否有使用DBNull.Value什么好处？ 这似乎更“正确”使用空，因为我们已经从数据库世界分开自己，但也有问题（你不能只是一味ToString()时，值为空，例如），所以它肯定是我们需要做出有意识的决定。
Answer 1:
我觉得它更好地使用空，而不是DB空。
究其原因是因为，如你所说，你从DB世界分离自己。
它通常是很好的做法，以检查引用类型，以确保它们不为空呢。 你将要检查空比DB数据之外的东西，我觉得这是最好保持一致性整个系统，并使用空，而不是DBNull 。
从长远来看，建筑我觉得这是更好的解决方案。
Answer 2:
如果你写你自己的ORM，那么我会说只是使用空，因为你可以使用它不过你想要的。 我相信的DBNull最初仅用于绕过事实值类型（int，日期时间等）不能为空，所以不是返回一些值为零一样或DateTime.Min，这将意味着空（坏，坏），他们创造的DBNull来表明这一点。 也许还有更多的，但我始终认为是原因。 然而，现在我们在C＃3.0具有可空类型，DBNull的不再是必要的。 事实上，LINQ to SQL的只是用空所有的地方。 一点问题都没有。 拥抱未来...使用空。 ;-)
Answer 3:
从我所经历过的.NET数据表和TableAdapter的工作有更好的DBNull。 这也开辟了一些特殊的方法时，强类型，如DataRow.IsFirstNameNull到位的时候。
我希望我可以给你比这更好的技术性的答复，但对我的底线是与数据库相关的对象时使用的DBNull，然后使用“标准”的空当我处理对象和.NET相关的代码。
Answer 4:
使用DBNull 。
我们使用空当encouintered某种问题。
如果我没有记错你不能插入一个空值的字段，只为DBNull。
可仅Oracle相关的，对不起，我不知道的细节了。
文章来源: C# Database Access: DBNull vs null
