Да, действительно закрытие задачи без коментариев не обновляют её дату. Надо tndt-83

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

Сортировка по автору задачи так и не работала, см tndt-32

Вынес проблему с лишними запросами в tndt-98. Здесь ограничимся join, который на самом деле работает.

Что-то это исследование выходит за рамки спецификаций, но это конское количество запросов выходит из-за User::getRoles() он нужен UserInterface для security, но он же является getter доктрины для User::$roles и доктрина, зачем-то перегидрирует релейшен projectUser, хотя он уже загружен

Ну что делаем пачку SpecBuilder.

При разделении слоев просто часть из них уйдут к филлерам.

И так в первом приближении репозитории переведены на спецификации. В них главное не забывать, что context это имя поля связи, а не его алиас (алиас вобще чисто sql’ное решение).

Осталось перевести на спецификации нашу элементарную систему заполнения условий из формы, и передачи в пагинатор

Третий вариант точно уходит на дальний рефакторинг, на после выделения presentation. Пока что спеки можно использовать везде, и репозитории то же. А вот куда их стремить вопрос. Давайте сначала переведем систему FilterCriteriaInterface SortCriteriaInterface, затем посмотрим что еще

В дальнейшем у нас есть 3 пути.

• Вынести сборку спецификаций в контроллеры, считая их допустимым внешним контрактом домена. Параллельно повторяющиеся условия вносить в новые спецификации вида PopularProjectsSpec. В целом все ради этого, но мне не очень нравится, что часть условий будут в контроллерах, часть в директории спецификаций.
• Оставить спецификации в репозиториях. Сразу возникает вопрос, а зачем тогда мучиться с join’ами там, где спокойно можно использовать queryBuilder
• Завести слой Supplier, и в нем делать сборку спецификаций, контролеры просто вызывают нужный саплаер. Во-первых требуем ли мы использования саплаеров жестко? Во вторых не будут ли они просто повторением репозиториев? Не появится ли куча пустых функций, тупо передающих управление таким же пустым функциям репозитория. В общем этот вариант стоит отложить до введения полноценной гексагональной архитектуры и разделения application на domain, application,infrastructure и не факт, что мы до этого дойдем.

Сейчас мы спецификациями просто заменяем QueryBuilder внутри репозиториев, оставляя снаружи их интерфейс таким же, как был, но это несколько снижает смысл спецификаций, так как это не просто замена qb, а поднятие логики выборок из инфраструктурного слоя с доменный. Но сейчас для выборок у нас просто нет доменного слоя.

Со спецификациями есть проблема, да, он позволяют добавить в неё join, но только простой, собирающий условия из описания связей таблицы. Если нам нужно добавить в join свое условие, это не работает.

Чтобы это обойти, мы добавили собственную спецификацию join, из-за которой инфраструктура слегка протекает в домен. В спецификации его использующий надо знать о работе QueryBuilder doctrine, чтобы передать ему корректное улосвие на DQL, плюс, к нему параметры

И так спецификации активно реализуются. Пока не дробим их сильно, в классы выносим только те, что явно будут использованы повторно. Сама идея реализуется очень классно, и методы репозиториев сильно сокращаются и упрощаются.

Застопорились на join. А именно на join в котором должно быть дополнительное условие внутри ON, а не снаружи. Думается в какой-то момент мы придем и к тому, что нам нужно будет делать спецификации c ON и спецификации WITH, это значит что-то важное, но я не помню что.

Мне кажется когда спецификации наберут в себя слишком много инфраструктурной логики, нужно будет просто делить их на два слоя, доменный, где не будет join/having вобще в принципе, и инфраструктурный который все это умеет. И трансформеры превращающие спецификации одного типа в другой.