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

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

G>>Поздравляю, вы изобрели свой IQueryable<T>, только гораздо более слабый и неудобный в использовании.

V>Я его инкапсулировал.

Нет, DataFetch делает ровно тоже, что и методы OrderBy, Top, Skip, при этом не дает никаких гарантий что Top и Skip применяются при наличии OrderBy.
Инкапсуляция, которая не дает дополнительных гарантий потребителю не нужна от слова вообще.



G>>Например текстовое поле SortBy как будет работать? Там же нужно считать агрегаты по связанным таблицам, поэтому просто передать Sort в ORDER BY не выйдет. В зависимости от значения Sort надо будет генерировать разные запросы, а это не решает исходную проблему. При добавлении сценария UI — надо править репозиторий, только вы скрыли проблему из интерфейса репозиториев и спрятали её в реализацию.

V>У меня сортировка по одному полю, поэтому этого SortBy мне достаточно. Если сортировка будет более сложной, то вместо текстовой строки я буду передавать что-то другое — зависит от условий задачи. А уж что там генерируется или делается за кулисами по этим полям, будет скрыто от внешнего мира.

Тогда возвращаемся к кейсу:
1) Показывать посты по дате добавления
2) Показывать посты по количеству оценок за день (самые популярные)
3) Показывать посты по комментов за день (самые обсуждаемые)

Во втором и третьем случае надо сделать join и посчитать реальное количество комментов\оценок за день. Обойтись SortBy по одному полю не выйдет.
Как в этом случае сделать репозитарии?
Кстати текстовый SortBy гораздо хуже лямбды в OrderBy.



G>>Также со временем ваш DataFetch распухнет, что его надежно использовать станет сложно.
V>Любой код распухнет при бесконечном изменении и расширении требований, в реальности новые требования перестают рано или поздно поступать или наступает дедлайн.
У вас распухнет в двух местах: появится много классов DataFetch или в него добавится неприлично много методов, а также распухнет обработчик этого монструозного класса(ов) DataFetch.
Если напрямую писать Linq и использовать комбинаторы, то распухать будет только в одном месте.

G>>Предположим в том же кейсе понадобилось добавить фильтр по тегам для трех описанных выше выборок, а также добавился ее один экран, где надо показывать посты текущего пользователя (без фильтра по тегам).
G>>Вы сделаете два разных DataFetch или будете кидать эксепшн на некорректном сочетании параметров?

V>В данном случае, теги и авторство вполне сочетаются. А если параметры точно не будут сочетаться, то тогда сделаю два разных класса.
В данном случае не сочетаются. По условиям задачи. Даже если эти условия вам не нарвятся легко придумать правдоподобные условия задачи, где будут две независимые выборки, и объединить их параметры в один DataFetch не выйдет.