Синтаксис LINQ, где строковое значение не равно null или пустое
Я пытаюсь сделать такой запрос...
query.Where(x => !string.IsNullOrEmpty(x.PropertyName));
но он терпит неудачу...
поэтому на данный момент я реализовал следующее, которое работает...
query.Where(x => (x.PropertyName ?? string.Empty) != string.Empty);
есть ли лучший (более собственный?) способ, которым LINQ обрабатывает это?
ИЗМЕНИТЬ
извиниться! не включал провайдера... Это использует LINQ to SQL
Ответы
Ответ 1
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=367077
Заявление о проблемах
Возможно написать LINQ to SQL, который получает все строки, которые имеют нулевую или пустую строку в заданном поле, но это невозможно для использования string.IsNullOrEmpty, хотя многие другие методы строк сопоставляются с LINQ to SQL.
Предложенное решение
Разрешить string.IsNullOrEmpty в предложении LINQ to SQL where, чтобы эти два запроса имели одинаковый результат:
var fieldNullOrEmpty =
from item in db.SomeTable
where item.SomeField == null || item.SomeField.Equals(string.Empty)
select item;
var fieldNullOrEmpty2 =
from item in db.SomeTable
where string.IsNullOrEmpty(item.SomeField)
select item;
Другое чтение:
1. DevArt
2. Dervalp.com
3. fooobar.com/questions/161820/...
Ответ 2
Это не сработает для Linq2Objects, но для Linq2SQL это не удастся, поэтому я предполагаю, что вы говорите о поставщике SQL или о чем-то подобном.
Причина связана с тем, как поставщик SQL обрабатывает ваше лямбда-выражение. Он не принимает его как функцию Func<P,T>
, а выражение Expression<Func<P,T>>
. Он берет это дерево выражений и переводит его так, что он является фактическим оператором SQL, который он отправляет на сервер.
Переводчик знает, как обращаться с основными операторами, но не знает, как обрабатывать методы на объектах. Он не знает, что IsNullOrEmpty(x)
переводит на return x == null || x == string.empty
. Это должно быть сделано явно для перевода в SQL.
Ответ 3
Это будет отлично работать с Linq to Objects. Однако некоторые поставщики LINQ испытывают трудности с запуском CLR-методов в рамках запроса. Это особенно верно для некоторых поставщиков баз данных.
Проблема заключается в том, что поставщики баз данных пытаются переместить и скомпилировать запрос LINQ в качестве запроса к базе данных, чтобы не допустить вытягивания всех объектов на провод. Это хорошо, но иногда ограничивает гибкость в ваших предикатах.
К сожалению, не проверяя документацию поставщика, трудно всегда точно знать, что будет или не будет поддерживаться непосредственно в провайдере. Похоже, ваш провайдер позволяет сравнивать, но не проверять строку. Я предполагаю, что в вашем случае это, вероятно, так же хорошо, как и вы. (Это действительно не то, что отличается от проверки IsNullOrEmpty, кроме создания экземпляра "string.Empty" для сравнения, но это второстепенное.)