Как оказалось весьма нетривиальная вещь. И так фильтры штуки разные, некоторые (фильтры по справочным полям) зависят от контекста проекта.

Хранить их той же структуре, в котором удобно передавать через query неудобно.

Фильтры явно являются контролами формы, а вот их набор динамический, статический, в виде коллекции или отдельной модели? Сортировка являясь частью модели вряд ли является контролами формы (точнее делать их так сложно) Впрочем не делать их так сложно сохранить все состояний настройки списка задач.

• Необходимо очень тщательно проработать иерархию моделей.
• Так же доделать набор контролов из которых будет собираться форма.
• Ну и пагинатор придется разрабатывать самостоятельно, впрочем это меньшая из проблем.

Мы тут в борьбе с симфонивскими формами развели какой-то непонятный и не поддерживаемый ад. При том, что не они диктуют формат. Сейчас у нас классические контролы, а в будущем мы может придем к языку запросов, в апи точно будут запросы. Так что надо идти от репозиториев и объектов хранения.

1. Создать модель настроек списка задач.
2. Заполнить её объектами фильтров, сортировок, пагинации
3. Создать спецификации и конверт в оные. Методы репозитория переделать на спецификации
4. Создать сервис перегоняющий объекты в отображения презентации, квери для урла, набор форм и просто контролов. И обратно из форм.
5. Сохранять в сессию натыканные фильтры