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

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

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

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

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

V>Что такое лямбды, джойны и OrderBy? Зачем вам, пользователю репозитория, об этом знать? Может там все посты в обычном текстовом файле хранятся.
Почему репозиторий определяет что я должен знать?
Я хочу задавать сортировку так, чтобы при переименовании поля код ругался. Лямбды для этого хорошо подходят, а linq идеально. Строки тут в жопе.


V>Сделаю поле вот такого типа и уже потом буду размышлять как это реализовать — через лямбды или строки.

V>

V>public enum PostSortingMethod
V>{
V>  Recent,
V>  HighlyRated,
V>  Flames
V>}
V>

То есть будет количество членов в enum по количеству разных выборок, а внутри будет большой swith. Это полностью аналогично разным методам. Более того разные методы даже удобнее, ибо списки параметров есть. А DataFetch позволяет легко не указать то, что надо.