Комментарии 8
Так ведь в шарп уже завезли Null-conditional operators:
customer?.Orders?[5]А они поддерживаются LINQ провайдерами, такими как EntityFramework? Если нет, то статья продолжает быть актуальной.
Было бы неплохо, если бы ваш пример демонстрировал работу в действительно унифицированном случае: то есть когда у нас есть IQueryable и мы не хотим знать, что за ним скрывается. То есть в случае если это некий источник данных, то оставляем Expression как есть, а вот в случае, если это IEnumerable — добавляем вызов With.
На самом деле, наверное это можно сделать. Для этого придется написать свой собственный extension method который будет использоваться для получения IQueriable из IEnumerable и написать свою реализацию IQueryProvider. Я попробую это сделать и сообщу о результатах.
Поскольку кода получилось много, я оформил этот пример в статью
Спасибо
А что произойдет в вашем случае если мы захотим написать
Ну и я так понял, что если лямбда чуть более сложная, то работать тоже ничего не будет
var authorFirstLetter = GetBookData(isbn, b=>b.Author.Name[0]);
Ну и я так понял, что если лямбда чуть более сложная, то работать тоже ничего не будет
var nameOrFamily = GetBookData(isbn, b => !string.IsNullOrEmpty(b.Author.Name) ? b.Author.Name : b.Author.Family);
Ваш код нельзя вызывать на IQueryable поверх бд. Он не затрансферится в sql код.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Унифицируем поведение LINQ to IEnumerable и LINQ to IQueriable в части работы с null значениями. Пример ExpressionVisitor