МСУАлексей КЯ говорю про случаи, когда в сервис надо выложить именно "всё". В веб-проектах, вероятно, такое не требуется. Но у меня WPF, тут такое требуется часто.
Ну хорошо, выложилось всё. Но причем тут логика (модель, code behind валидация) и презентационный слой (UI, валидация)?Там трёхзвенка. Я хочу увидеть в вебсервисе объект, соответствующий таблице в БД.

МСУАлексей КМаксимум что там можно сделать, это подставить выражение в один из расширяющих методов класса Queryable (Where, Select и т. п.). Мне этого недостаточно.
Почему же, ты точно так же можешь конструировать весь отложенный запрос или несколько.Не точно так же. Гибкости подставляемых выражений там не добиться.

МСУАлексей КИ как мы будем подставлять IL, живущий в Func<>, в LINQ Expression?
Какой IL? Я про Func<A, B> predicate, который можно передавать в аргументы.Func<A, B> vs Expression<Func<A, B>>

Есть разница? :-)

МСУАлексей КПотому что при использовании подставляемых выражений с повторным использованием всё в порядке.
Какие в результирущем IQueryable "подставляемые выражения"? IQueryable не может быть результирующим, результирующим может быть List<T>. IQueryable - это фрагмент запроса, как вьюха в БД, которая сама по себе не имеет плана выполнения, план выполнения имеет запрос к вьюхе.

МСУАлексей Кпропущено...
Это проблема не IQueryable как такового, а проблема автора, который не добавил в проект необходимой абстракции.



Неправильный ответ. Ты отдаешь IQueryable, чтобы его потом можно было еще дофильтровывать. Так вот о этой дофильтровке и идет речь. В 10 местах ты использовал дофильтровку, потом появился новый признак в БД, который должен учитываться во всех дофильтровках и мы получили в бубен.Я отдаю IQueryable, чтобы на его базе можно было построить множество запросов. Если фильтр, о котором ты говоришь, нужно сделать в одном месте - он будет сделан в одном месте.

МСУАлексей КТам трёхзвенка. Я хочу увидеть в вебсервисе объект, соответствующий таблице в БД.
То есть у тебя все запросы вида "SELECT * FROM"? В форму редактирования уходит объект, сгенерированный по таблице из базы. Это select * from ?

МСУАлексей КНе точно так же. Гибкости подставляемых выражений там не добиться.
В чем выражена эта гибкость? )Тут в двух словах не расскажешь, бери пробуй. Я попробовал - мне понравилось. :-)

МСУАлексей КFunc<A, B> vs Expression<Func<A, B>>
Есть разница? :-)
Не придирайся. Разумеется имелось ввиду Expression + Func, а не голый Func в качестве аргумента :)У меня телепатор в ремонте.

МСУАлексей КIQueryable не может быть результирующим, результирующим может быть List<T>. IQueryable - это фрагмент запроса, как вьюха в БД, которая сама по себе не имеет плана выполнения, план выполнения имеет запрос к вьюхе.
Не нужен никому фрагмент запроса, потребителю нужен готовый к съедению набор.Потребители разные бывают.

МСУАлексей КЯ отдаю IQueryable, чтобы на его базе можно было построить множество запросов. Если фильтр, о котором ты говоришь, нужно сделать в одном месте - он будет сделан в одном месте.
Нельзя этого делать, тебе ж объяснили почему. Если потребуется усечь выборку (новое требование) при помощи [Where IsDeleted = False], тебе придется это делать в 100500 местах прикладного кода.Ах вот ты о чём. :-)


Обрати внимание, IsActive описано в одном месте.

from d in D1

опечатка

МСУА через выражения это выглядит ещё красивее

skyANAИ кстати люди постоянно забывают, что репозиторий призван скрыть от нас то, как распредены данные.Если мы готовы к "N+1", можно и скрыть. Всё зависит от задачи.

hVosttskyANAИ кстати люди постоянно забывают, что репозиторий призван скрыть от нас то, как распредены данные.
Сегодня вы используете SQL Server, EF и OData, всё глатко и пушисто.
А завтра часть данных берётся из NoSQL хранилища, кэшируется в Couchbase... И приехали.
Пишите, Шура, пишите новые IQueryProvider-ы, а то что-то ни фига не работает.

это единственный разумный аргумент. но с другой стороны, для более менее популярных хранилищ LINQ провайдеры активно пишутся. это как стандарт де-факто. практически тоже самое можно прикатать даже к SQL ++

hVosttАлексей Кпропущено...
Если мы готовы к "N+1", можно и скрыть. Всё зависит от задачи.

они просто говорят о репозитории, который является и в то же время моделью. модель (в понимании MVC), даже близко не является репозиторием, она его использует. это видимо и есть N+1 в вашем понимании.Я о том, что такой подход приведёт к необходимости множества методов типа GetMyEntityByID(int id) , что в свою очередь приведёт к N+1. IQueryable избавляет от этой напасти.

skyANAhVosttпропущено...


это единственный разумный аргумент. но с другой стороны, для более менее популярных хранилищ LINQ провайдеры активно пишутся. это как стандарт де-факто. практически тоже самое можно прикатать даже к SQL А много ты знаешь НЕ реляционных хранилищ, что поддерживают запросы в каком-либо виде? А для каких из них реализованы LINQ провайдеры?

P.S.: плюс данные могут браться и не из нашего хранилища, а запрашиваться со сторонних сервисов (наших партнёров, публичных и т.п.).Речь идёт о реализации логики к одной SQL базе. Понятно, что если баз много или они не-SQL, IQueryable тут вряд ли пригодится.