как сделать так чтобы Shemas генерировались с Entity
Я пару лет уже не писал, но помню брали тег @Model, и с ним работало.
Не минусил, но если интересуют замечания, то могу немного набросать из того, что сразу бросилось в глаза:
private ApiFrontendService $apiFrontendService;
Вы используете новую версию PHP, там можно свойство в конструктор внести, чтобы было меньше бойлерплейта. И apiFrontendService можно сразу на вход конструктора запросить, резолв зависимостей — задача фреймворка, симфони эту работу хорошо делает.
Request $request
Возможно для описанных примеров был бы удобнее doctrine-конвертер, он позволяет подать на вход контроллера сразу сущность.
Запросы к бд прямо в сервисе или контроллере, логика изменений в контроллере (editDepartament) вместо сервиса — эти моменты могут вызвать расстройство у опытных читателей, но тут можно оговориться, что у нас логики мало, сущности единообразные, плюс у нас хакатон, поэтому мы не выносим запросы в классы-репозитории и где-то ленимся еще сильнее и не выносим обработку в сервис. Такая оговорка также подскажет новичкам, что не стоит код копировать как есть в свои тестовые.
А вот возврат JsonResponse из сервиса, на мой взгляд, более грубое действие. Формат отдачи, как и код возврата — это работа контроллера. Сервис лучше держать удобным для обращения из других внешних точек: вызовов из консольной команды или из консюмера, а не только из контроллера. К тому же это довольно быстрая правка даже в контексте хакатона.
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда, но для статьи код желательно причесать под PSR-12: добавить strict_types, поправить отступы (первые строчки разные даже у приложенных двух файлов), скобки ")]" у OAT где-то на одной строке, где-то отдельно на разных. Это мелочи, но с ними код читается приятнее и выглядит более привычно.
За статью спасибо, легко читается. Взять новый для себя язык и фреймворк для хакатона — смело, справиться — вообще круто, видно опыт в IT. Отдельно хочется отметить swagger-аннотации: приятно видеть, что сделана не только апишка, но и дока к ней для удобства участников команды.
Я пару лет уже не писал, но помню брали тег @Model, и с ним работало.
Не минусил, но если интересуют замечания, то могу немного набросать из того, что сразу бросилось в глаза:
Вы используете новую версию PHP, там можно свойство в конструктор внести, чтобы было меньше бойлерплейта. И apiFrontendService можно сразу на вход конструктора запросить, резолв зависимостей — задача фреймворка, симфони эту работу хорошо делает.
Возможно для описанных примеров был бы удобнее doctrine-конвертер, он позволяет подать на вход контроллера сразу сущность.
Запросы к бд прямо в сервисе или контроллере, логика изменений в контроллере (editDepartament) вместо сервиса — эти моменты могут вызвать расстройство у опытных читателей, но тут можно оговориться, что у нас логики мало, сущности единообразные, плюс у нас хакатон, поэтому мы не выносим запросы в классы-репозитории и где-то ленимся еще сильнее и не выносим обработку в сервис. Такая оговорка также подскажет новичкам, что не стоит код копировать как есть в свои тестовые.
А вот возврат JsonResponse из сервиса, на мой взгляд, более грубое действие. Формат отдачи, как и код возврата — это работа контроллера. Сервис лучше держать удобным для обращения из других внешних точек: вызовов из консольной команды или из консюмера, а не только из контроллера. К тому же это довольно быстрая правка даже в контексте хакатона.
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда, но для статьи код желательно причесать под PSR-12: добавить strict_types, поправить отступы (первые строчки разные даже у приложенных двух файлов), скобки ")]" у OAT где-то на одной строке, где-то отдельно на разных. Это мелочи, но с ними код читается приятнее и выглядит более привычно.
За статью спасибо, легко читается. Взять новый для себя язык и фреймворк для хакатона — смело, справиться — вообще круто, видно опыт в IT. Отдельно хочется отметить swagger-аннотации: приятно видеть, что сделана не только апишка, но и дока к ней для удобства участников команды.