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

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

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

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

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

G>Также со временем ваш DataFetch распухнет, что его надежно использовать станет сложно.

Любой код распухнет при бесконечном изменении и расширении требований, в реальности новые требования перестают рано или поздно поступать или наступает дедлайн.

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

В данном случае, теги и авторство вполне сочетаются. А если параметры точно не будут сочетаться, то тогда сделаю два разных класса.