Здарова всем! Подскажите, плиз, где лучше размещать логику приложения в

симфонии? Логика по типу: кастомная авторизация и прочее. В сервисах подойдёт?

На первое время да. Главное не забывать про SOLID. Особенно про последнюю букву.

Что значит на первое время?

Всё от сложности проекта зависит. Мб тебе и этого станет вполне достаточно. Но если нет, то на горизонте DDD и вот это вот всё.

Редактирование, Удаление, Создание - чего-то Регистрация, Авторизация, Восстановление пароля

Это все api

Смотри как у меня было в своём фрейме: В папке app -> Services Я создавал папку с функционалом, например Track и в этой папке я создал уже сервисы: AddTrackService, AddSubtitlesService и т.д., но из-за того что я не сделал реализацию кастомных окружений тесты написать под апи не могу и пришлось на симфони переезжать и сейчас нужно будет переписать более 30к кода и вот сейчас думаю как это будет лучше сделать, чтоб потом не делать большой рефакторинг

В целом у вас норм, если вы понимаете, что это у вас это сервисы приложения (есть сервисы домена, а есть приложения). На 100 сообщений выше было общение про разделение на контексты и юзкейсы (ваши сервисы) в них . Один из вариантов - вот такой https://github.com/ElisDN/demo-project-manager/tree/master/manager

Папка Service ?

Название спорное, потому что могут потом возникнуть проблемы, как называть и какую папку выделить под сервисы домена, или какие то другие сервисы (аплоадеры например, обработчики картинок)

https://github.com/codememory1/music-service у меня сделано сейчас так, т.е., общие сервисы я выношу в ./ а под другое создаю папки в сервисе

Пример выше скинул, как пишут некоторые на симфони, сравнивайте :)

Nikolay Deriglazov
В первом же попавшемся мне конструкторе вижу высок...

D - инверсия зависимостей

Nikolay Deriglazov
В первом же попавшемся мне конструкторе вижу высок...

Этот пакет был сделан на скорую руку, чтоб иметь возможность разделить логику от контроллеров

Nikolay Deriglazov
В первом же попавшемся мне конструкторе вижу высок...

Человек на обмазался везде интерфейсами, все, плохлой проект, SOLID упал?

Nikolay Deriglazov
Как ты на это напишешь юнит-тест?

Я не буду писать юнит на юзкейс

Nikolay Deriglazov
Как ты на это напишешь юнит-тест?

Это api как бы

Nikolay Deriglazov
Как ты на это напишешь юнит-тест?

А то, что там repository в конструкторе инициализируются, что тут плохого? Мне его в методе инициализировать, а потом делать по 100 параметров ?

В том, что этот сервис - такой же юнит как и любой другой класс системы. И он должен быть тестируемым. Если он тестируем обычным юнит-тестом - то у него нет высокого каплинга.

Ммм… Интересно, а зачем писать тест на api маршрут, а потом писать на сервис, который вызывается в маршруте, который уже протестирован ?

Любой класс можно протестить юнтом, вопрос лишь от боли в моках и сложности логики. Причем тут каплинг? Если был бы интерфейс, что бы это дало в тесте?

Я еще понимаю, языки где дне нельзя сделать мок без интерфейса. У нас то можно

Nikolay Deriglazov
Как ты на это напишешь юнит-тест?

findById() по любому в абстрактном лежит, а не в вашем

Верно

Это уже нужно смотреть пакет codememory/orm