Синтаксис 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" для сравнения, но это второстепенное.)