Алексей КГлавное - иметь своё мнение. И если оно отличается от мнения большинства, это ещё не значит, что оно неправильное. Ну да Бог с ней, с философией... :-)
Мнение большинства: биться о бетонную стену головой опасно.
Мнение Васи Кожевникова (сисадмин в головной компании РЖД): всё это хрень, биться головой о бетонную стену можно и нужно - прояснение ума и осознание истинного бытия.

Алексей КЕсли по теме - хочется обсудить архитектуру, ориентированную на конкретную СУБД + EF + максимальная производительность.
Я так и не понял, почему у репозитория с IEnumerable хуже производительность, чем с IQueryable

SerP19833) И самая главная причина: зависимость от MSSQL + EF. Изменится источник или хранилище данных - приплыли.
Вот этого совсем не понял.



Ну это жесть какая-то. У одних методов репозтория IQueryable - отложенный запрос, который после транслируется в SQL - это тонкая специфика и понимание, с какой именно БД работаем. Иначе будет ошибка и запрос не сможет транслироваться. У других методов IQueryable не заточен под конкретную БД и представляет собой клиентскую коллекцию. Каша.

Во что ретранслируется этот запрос и что он мне вернет?




Бред же.

Алексей К"Разруха, она в головах." (ц)
... которые используют IQueryable методы в репозиториях :)

Алексей КМСУБред же.Это как посмотреть. IQueryable позволяет на сервере приложений организовать окружение, напоминающее окружение в хранимой процедуре в БД. Например, IQueryable-свойство является аналогом View из T-SQL. Дополнительные возможности - это скорее хорошо чем плохо. Единственный недостаток - надо уметь ими пользоваться.
Какое еще окружение? Или ты про кашу IQueryable, которая не пойми что возвращает: в одних случаях это отложенный сиквел запрос с последующей ретрансляцией, в других это просто клиентская коллекция. Может тебе посмотреть на OData?

SerP19832 skyANA и МСУ

Спасибо, понял. Согласен, что IQueryProvider писать не айс; согласен, что для каждого IQueryProvider есть своя специфика и, если отдавать наружу IQueryable, можно словить жопу.

Предлагаю рассмотреть 2 случая:

1) Опять повторюсь, что у devexpress есть возможность работать с гридом асинхронно (подгружать строки при скроле). Для этого надо использовать LinqInstantFeedbackSource,
EntityInstantFeedbackSource, ещечегототамInstantFeedbackSource. При этом код писать практически не надо. Но для InstantFeedbackSource надо указывать Source как IQueryable.

2) Если посмотреть на domainservice (мертвый ria который) или на dataservice (живой OData), то там можно наружу выдавать IQueryable.

Вопрос: мне в этих 2-х случаях отказаться от репозитория и напрямую пользовать контекст или сделать репозиторий с IQueryable?
1. Вся беда, что ты под какие-то там компоненты пытаешься рихтовать архитектуру. Это не айс.
2. Про OData уже писал, это отдельный специфический продукт, который заточен под IQueryable. Более того, OData - это не репозиторий, там ты сам контроллер ApiController обязываешь играть по правилам IQueryable. Вообщем, это отдельная тема.