C＃數據庫訪問：DBNull vs null

Question

我們在這里使用自己的ORM，並為所有db表提供強類型包裝器。 我們還允許執行弱類型的臨時SQL，但是這些查詢仍然通過相同的類來從數據讀取器中獲取值。

在調整該類以使用Oracle時，我們遇到了一個有趣的問題。 使用DBNull.Value或null是否更好？ 使用DBNull.Value有什么好處嗎？ 使用null似乎更“正確”，因為我們已經將自己與數據庫世界分開了，但是有一些含義（例如，當值為null時，你不能盲目地使用ToString() ）因此它絕對是我們需要的東西做出有意識的決定。

Answer 1

我發現使用null更好，而不是DB null。

原因是，正如您所說，您將自己與數據庫世界分開。

通常，檢查引用類型以確保它們不為空是一種好習慣。 您將檢查除DB數據之外的其他內容的null，並且我發現最好保持整個系統的一致性，並使用null，而不是DBNull 。

從長遠來看，在架構上我發現它是更好的解決方案。

Answer 2

如果您已經編寫了自己的ORM，那么我會說只使用null，因為您可以隨意使用它。 我相信DBNull最初只用於解決值類型（int，DateTime等）不能為空的事實，所以不要返回像zero或DateTime.Min這樣的值，這意味着 null（壞，壞） ），他們創建了DBNull來表明這一點。 也許還有更多，但我一直認為這就是原因。 但是，現在我們在C＃3.0中有可空類型，不再需要DBNull。 事實上，LINQ to SQL只是在所有地方使用null。 沒問題。 擁抱未來......使用null。 ;-)

Answer 3

根據我的經驗，.NET DataTables和TableAdapter可以更好地與DBNull配合使用。 當強類型時，它還會打開一些特殊方法，例如DataRow.IsFirstNameNull。

我希望我能給你一個比這更好的技術答案，但對我來說，底線是在處理數據庫相關對象時使用DBNull，然后在處理對象和.NET相關代碼時使用“標准”null。

Answer 4

使用DBNull 。
我們鼓勵在使用null時遇到一些問題。
如果我沒記錯，你不能將空值插入字段，只有DBNull。
可能只是甲骨文相關，對不起，我不知道細節了。