|| (или) Оператор в Linq с C #

Прочтите эту документацию, в которой объясняется, как linq и C # могут испытывать Отключить.

Поскольку ожидается, что выражения Linq будут сокращены до чего-то другого, кроме простых методов, вы можете обнаружить, что этот код ломается, если позже он используется в каком-либо контексте, отличном от Linq to Objects.

Это сказал

String.IsNullOrEmpty(fromname) || 
(   !String.IsNullOrEmpty(fromname) && 
    msg.FromName.ToLower().Contains(fromname.ToLower())
)

Плохо сформирован, так как он действительно должен быть

String.IsNullOrEmpty(fromname) || 
msg.FromName.ToLower().Contains(fromname.ToLower())

что делает приятным и ясным, что вы полагаетесь на то, что msg и msg.FromName оба также не равны нулю.

Чтобы упростить себе жизнь в C #, вы можете добавить следующий метод расширения строки

public static class ExtensionMethods
{
    public static bool Contains(
        this string self, string value, StringComparison comparison)
    {
        return self.IndexOf(value, comparison) >= 0;
    }

    public static bool ContainsOrNull(
        this string self, string value, StringComparison comparison)
    {
        if (value == null)
            return false;
        return self.IndexOf(value, comparison) >= 0;
    }
}

Затем используйте:

var messages = (from msg in dc.MessageItems
where  msg.FromName.ContainsOrNull(
    fromname, StringComparison.InvariantCultureIgnoreCase)
select msg);

Однако проблема не в этом. Проблема в том, что аспекты системы Linq to SQL пытаются использовать значение fromname для построения запроса, который отправляется на сервер.

Поскольку fromname является переменной, механизм перевода отключается и выполняет то, что от него требуется (создавая представление fromname в нижнем регистре, даже если оно равно нулю, что вызывает исключение).

в этом случае вы можете либо сделать то, что вы уже обнаружили: оставить запрос как есть, но убедиться, что вы всегда можете создать ненулевое значение fromname с желаемым поведением, даже если оно равно нулю.

Возможно, лучше было бы:

IEnumerable<MessageItem> results;
if (string.IsNullOrEmpty(fromname))
{ 
    results = from msg in dc.MessageItems 
    select msg;    
}
else
{
    results = from msg in dc.MessageItems 
    where msg.FromName.ToLower().Contains(fromname) 
    select msg;    
}

Это не так уж важно, если запрос содержал другие ограничения и, таким образом, вызвал большее дублирование, но для простого запроса на самом деле должен приводить к более читаемому / поддерживаемому коду. Это неприятно, если вы полагаетесь на анонимные типы, но, надеюсь, это не проблема для вас.

Хорошо. Я нашел решение.

Я изменил оскорбительную строку на:

where (String.IsNullOrEmpty(fromemail)  || (msg.FromEmail.ToLower().Contains((fromemail ?? String.Empty).ToLower())))

Работает, но похоже на взлом. Я уверен, что если первое выражение истинно, второе не должно оцениваться.

Было бы здорово, если бы кто-нибудь мог подтвердить или опровергнуть это для меня ...

Или, если у кого-то есть лучшее решение, дайте мне знать !!!

Если вы используете LINQ to SQL, вы не можете ожидать такого же поведения короткого замыкания C # в SQL Server. См. этот вопрос о предложениях WHERE короткого замыкания (или их отсутствии) в SQL Server.

Кроме того, как я уже упоминал в комментарии, я не верю, что вы получаете это исключение в LINQ to SQL, потому что:

1. Метод String.IsNullOrEmpty(String) не поддерживает преобразование в SQL, поэтому его нельзя использовать в LINQ to SQL.
2. Вы бы не получили исключение NullReferenceException. Это управляемое исключение, оно может произойти только на стороне клиента, а не в SQL Server.

Вы уверены, что это где-то не проходит через LINQ to Objects? Вы вызываете ToList () или ToArray () в своем источнике или ссылаетесь на него как на IEnumerable ‹T› перед выполнением этого запроса?

Обновление: Прочитав ваши комментарии, я снова проверил это и кое-что понял. Я ошибался, говоря, что вы не используете LINQ to SQL. Вы не получали исключение "String.IsNullOrEmpty(String) has no supported translation to SQL", потому что IsNullOrEmpty() вызывается для локальной переменной, а не для столбца SQL, поэтому он работает на стороне клиента, даже если вы используете LINQ to SQL (не LINQ to Objects ). Поскольку он выполняется на стороне клиента, вы можете получить NullReferenceException при вызове этого метода, потому что он не транслируется в SQL, где вы не можете получить NullReferenceException.

Один из способов сделать ваше решение менее хакерским - разрешить fromname "нулевое значение" вне запроса:

string lowerfromname = String.IsNullOrEmpty(fromname) ? fromname : fromname.ToLower();

var messages = from msg in dc.MessageItems
               where String.IsNullOrEmpty(lowerfromname) || msg.Name.ToLower().Contains(lowerfromname)
               select msg.Name;

Обратите внимание, что это не всегда будет переведено на что-то вроде (используя ваши комментарии в качестве примера):

SELECT ... FROM ... WHERE @theValue IS NULL OR @theValue = theValue

Его перевод будет определен во время выполнения в зависимости от того, является ли fromname нулевым или нет. Если он равен нулю, он будет переведен без предложения WHERE. Если он не равен нулю, он будет транслироваться простым "WHERE @theValue = theValue" без проверки на нуль в T-SQL.

Итак, в конце концов, вопрос о том, будет ли это короткое замыкание в SQL или нет, в этом случае не имеет значения, потому что среда выполнения LINQ to SQL будет выдавать разные запросы T-SQL, если fromname имеет значение NULL или нет. В некотором смысле, перед запросом к базе данных происходит короткое замыкание на стороне клиента.

Вы уверены, что это значение «fromname» равно нулю, а не «msg.FromName», которое имеет значение NULL?

Как сказал Брайан, я бы посмотрел, имеет ли msg.FromName значение null, прежде чем выполнять ToLower (). Contains (fromname.ToLower ()))

Вы правы, что второе условное выражение не должно оцениваться, поскольку вы используете сравнения короткого замыкания (см. Какова наилучшая практика в отношении оценки короткого замыкания C #?), однако я подозреваю, что Linq может попытаться оптимизировать ваш запрос перед его выполнением и при этом может изменить порядок выполнения.

Заключение всего этого в скобки, на мой взгляд, дает более ясное утверждение, поскольку все условие «где» содержится в скобках.