Здравствуйте, gandjustas, Вы писали:

G>Затем что запрос эффективнее строить там где наиболее полно известна информация об этом запросе. А известна она на уровне UI.
G>Например:
G>1)Пользователь нажал на страницу 2 в списке каких-то объектов
G>2)В UI есть информация какой список объектов нужен и что вызвана страница 2
G>3)Код PL выполняет получение списка объектов из сервиса BL (IQueryable) и выполняет разбивку на страницы .Skip(...).Take(...), накладывает проекции, материализует для передачи UI.
G>3)Сервис BL получает от Repository IQueryable, фильтрует все Hidden объекты и накладывает предикаты видимости в зависимости от роли пользователя.
G>4)Repository является тонкой оберткой на ORM, чтобы в тестах его можно было заменить на что-то полегче.

G>Если не протаскивать IQueryable, то придется "протаскивать" передачу параметров из UI в нижние слои. Причем под каждый набор параметров понадобится свой метод, что приведет у увеличению количества методов, копипасте и другим плохим вещам.

Протаскивается только предикат и протаскивается в одну сторону. Против этого я ничего не имею. Все протаскивание выглядит так PL->BL->DAL.

Обертку ORM для облегчения тестирования, конечно, сделать можно, только зачем называть ее Repository и делать для каждой сущности? Тем более мок фреймворки могут делать такие обертки на лету. Я же тестирую такие вещи прямо на базе с тестовыми данными, не идеально, но работает. Заодно позволяет заметить некоторые проблемы производительности.