My<cod/>.net
C# доступ к базе данных: DBNull vs null
У нас есть свой ORM, который мы используем здесь, и предоставляем строго типизированные оболочки для всех наших таблиц БД. Мы также допускаем выполнение слабо типизированного ad-hoc SQL, но эти запросы все равно проходят через один и тот же класс для получения значений из считывателя данных.
При настройке этого класса для работы с Oracle мы столкнулись с интересным вопросом. Лучше ли использовать DBNull.Value, или null? Есть ли какие-то преимущества в использовании DBNull.Value? Кажется, что больше "correct" использовать null, так как мы отделили себя от мира DB, но есть последствия (вы не можете просто слепо ToString() , когда значение null, например), так что это определенно то, что нам нужно сделать сознательное решение.
Я считаю, что лучше использовать null, а не DB null.
Причина в том, что, как вы сказали, вы отделяете себя от мира DB.
Обычно рекомендуется проверять ссылочные типы, чтобы убедиться, что они не являются null в любом случае. Вы будете проверять наличие null для других вещей, кроме данных DB, и я считаю, что лучше всего поддерживать согласованность в системе и использовать null, а не DBNull .
В конечном счете, с точки зрения архитектуры, я считаю, что это лучшее решение.
Если вы написали свой собственный ORM, то я бы сказал просто использовать null, так как вы можете использовать его так, как вы хотите. Я считаю, что DBNull изначально использовался только для того, чтобы обойти тот факт, что типы значений (int, DateTime и т. д.) не может быть null, поэтому вместо того, чтобы возвращать какое-то значение, например ноль или DateTime.Min, что означало бы null (плохо, плохо), они создали DBNull, чтобы указать на это. Может быть, в этом было что-то еще, но я всегда предполагал, что причина именно в этом. Однако теперь, когда у нас есть nullable типы в C# 3.0, DBNull больше не нужно. На самом деле, LINQ-SQL просто использует null повсюду. Вообще никаких проблем. Объятия будущего... используйте null. ;-)
Судя по моему опыту, .NET DataTables и TableAdapters лучше работают с DBNull. Он также открывает несколько специальных методов при сильном типировании, таких как DataRow.IsFirstNameNull, когда он находится на месте.
Я хотел бы дать вам лучший технический ответ, но для меня суть заключается в использовании DBNull при работе с объектами, связанными с базой данных, а затем использовать "standard" null, когда я имею дело с объектами и .NET связанным кодом.