Есть ли у кого-то предпочтение в том, как проверить, является ли значение DBNull? Я нашел, что эти два утверждения дают мне результаты, которые я хочу, но просто интересно, есть ли предпочтения?(any == System.DBNull.Value) vs (any is System.DBNull)
if (any is System.DBNull)
же, как:
if (any == System.DBNull.Value)
Спасибо!
if (any == System.DBNull.Value) ...
Я предпочитаю это, просто потому, что прочитал это как сравнение значений, а не типов.
Если вы находитесь в C#, вы должны использовать ==; is использует отражение, которое дороже для вычисления, тем более, что существует только один экземпляр System.DBNull.
-1 для неправильной инструкции 'использует отражение'. Нет проблемы с производительностью с помощью 'is'. (Чтобы быть более точным, то, что обычно называют «использованием отражения», - это использовать методы в System.Reflection, которые действительно медленны. Поэтому, чтобы размахивать руками, используя 'is', как« использование отражения », в лучшем случае вводит в заблуждение. Поэтому вводить в заблуждение, что этот ответчик УТВЕРДИЛ, что результат должен быть медленным. Вы на самом деле ** испытали ** это предположение? Нет) – ToolmakerSteve
Мне нравится «is System.DBNull» больше, потому что я ненавижу идею сравнивать что-то с NULL и быть правдой. Многие другие синтаксисы (какого черта это множественное число?) Имели бы что-нибудь == NULL, возвращающее NULL.
Я понимаю, что есть DBNull.Value по причине. Я знаю. Я перечисляю мой ПРЕДПОЧТЕНИЕ :)
А? Это вопрос .Net. 'x == null' НЕ возвращает' null'. Выполняя поиск в Google, я не нашел другого языка, на котором он работает. Возможно, вы думаете о поплавковых операциях, где 'x == undefined' возвращает' undefined'. Но это отличается от «null». «null» имеет конкретное значение, и его действительно можно сравнить. Более подробную информацию о том, что такое сравнение означает, является ли это хорошей идеей или нет, см. Http://stackoverflow.com/questions/3507383/equalsitem-null-or-item-null (И на C++, из которого много синтаксиса C# s, часто НЕОБХОДИМО сравнивать с «null».) – ToolmakerSteve
Привет @ToolmakerSteve! Мальчик, это старый вопрос, на который ты опускаешься.Это связано с данными, а в SQL сравнение (somevar = null) возвращает null. – nathaniel
Я предпочитаю использовать
if (DBNull.Value.Equals(value)) {
//
}
или
if (Convert.IsDBNull(value)) {
//
}
is не использует отражение, как говорит Kevlar623. Он сопоставляется с операцией isinst в Ил. На этом уровне сравнение производительности просто глупо, если только вы не работаете над системой управления ракетами.
Я использую value is DBNull. Это просто звучит правильно и как разработчик параноиков, я не могу доверить, что единственное значение, которое когда-либо существовало, - DBNull.Value. Происходят ошибки.
Я бы больше беспокоился о других ошибках, чем о том, будет ли запечатанный системный класс с единственным значением «Value» каким-то образом прорасти второе значение. Однако я согласен с вами не потому, что я параноик, а потому, что тест против DBNull.Value, на мой взгляд, предполагает, что ** может быть ** некоторым другим DBNull. Я знаю *, нет, но зачем писать код, который звучит так, как будто это относится к определенному DBNull, когда действительно есть только один? Мне всегда казалось глупым. – ToolmakerSteve
Это хороший пример формы, следующей за функцией. Каким бы ни было более эффективным, это путь. То, как это выглядит, читает, или плохие имена, которые он вам называет, не имеет значения. Используйте язык эффективно, не форматируйте язык в новый.
-1 - Это не ответ. Если бы вы включили какие-либо доказательства в отношении **, которая ** была бы более быстрой, тогда это был бы ответ. – ToolmakerSteve
+1 хороший вопрос. – nawfal