Доступ к базе данных C #: DBNull против нуля - PullRequest
13 голосов
/ 16 августа 2008

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

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

Ответы [ 4 ]

15 голосов
/ 16 августа 2008

Я считаю, что лучше использовать нулевое значение, а не нулевое значение БД.

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

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

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

7 голосов
/ 16 августа 2008

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

3 голосов
/ 16 августа 2008

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

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

1 голос
/ 16 августа 2008

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

...