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