Доступ к базе данных С#: DBNull vs null

У нас есть наш собственный ORM, который мы используем здесь, и предоставляем строго типизированные обертки для всех наших таблиц db. Мы также разрешаем использовать слабо типизированный ad-hoc SQL, но эти запросы по-прежнему проходят через один и тот же класс для получения значений из устройства чтения данных.

При настройке этого класса на работу с Oracle мы сталкиваемся с интересным вопросом. Лучше ли использовать DBNull.Value или null? Существуют ли какие-либо преимущества использования DBNull.Value? Кажется более "правильным" использовать null, так как мы отделились от мира БД, но есть последствия (вы можете не просто слепо ToString(), когда значение равно null), поэтому его определенно нам нужно принять осознанное решение.

Ответ 1

Я считаю, что лучше использовать null вместо DB null.

Причина в том, что, как вы сказали, вы отделяетесь от мира БД.

Обычно рекомендуется проверять типы ссылок, чтобы гарантировать, что они не являются нулевыми. Вы будете проверять значение null для данных, отличных от данных БД, и я считаю, что лучше всего поддерживать согласованность в системе и использовать значение null, а не DBNull.

В долгосрочной перспективе, архитектурно, я считаю, что это лучшее решение.

Ответ 2

Если вы написали свой собственный ORM, я бы сказал, что просто использую null, так как вы можете использовать его, как хотите. Я считаю, что DBNull изначально использовался только для того, чтобы обойти тот факт, что типы значений (int, DateTime и т.д.) Не могут быть нулевыми, поэтому вместо того, чтобы возвращать какое-то значение, например zero или DateTime.Min, что подразумевает нулевое (плохое, плохое)), они создали DBNull, чтобы указать это. Возможно, было больше, но я всегда считал, что это причина. Однако теперь, когда у нас есть типы с нулевым значением в С# 3.0, DBNull больше не нужен. На самом деле LINQ to SQL просто использует нуль везде. Совершенно никаких проблем. Embrace будущее... использование null.; -)

Ответ 3

Из опыта, который у меня был,.NET DataTables и TableAdapters работают лучше с DBNull. Он также открывает несколько специальных методов, когда они строго типизированы, например DataRow.IsFirstNameNull, когда они на месте.

Я бы хотел дать вам лучший технический ответ, но для меня в нижней строке используется DBNull при работе с объектами, связанными с базой данных, а затем использовать "стандартный" нуль, когда я имею дело с объектами и .NET. связанный код.

Ответ 4

Используйте DBNull.
Мы использовали некоторые проблемы при использовании null. Если я правильно помню, вы не можете Вставить значение null в поле, только DBNull.
Может быть, только Oracle связан, извините, я больше не знаю деталей.