Как организовать структуру Symfony проекта для взаимодействия со сторонним API?

Question

[joker8989]

Есть развернутое приложение на symfony/skeleton. Основная задача: в контроллерах получать данные из стороннего API (нет взаимодействия с БД)
Данные это конкретные сущности (Посты, Клиенты, Заказы и др.).

Суть вопроса как организовать структуру проекта? C symfony работаю первый раз.

1. Можно ли каждую сущность представить сервисом?
Например Service/PostService.php или это лучше сделать репозиторием? Или есть другие варианты?

2. Как получать данные для таких сущностей?
Сейчас сделал отдельный класс ApiClient.php который внтури создает guzzle client и обращается к стороннему api

3. Как связать класс сущности с api клиентом?
Создал отдельный сервис ApiService.php от которого наследуются сервисы которым нужно получать данные из api. В конструкторе этого класса создается ApiClient.
И в дочерних сервисах могу делать запросы к api такого вида: $this->api->apiMethod();

Буду очень признателен если подскажете что улучшить.

Answer 1

[Евгений Самсонов]

Структура Entity -> Repository -> Service -> Controller универсальна и не завязана на БД.

Entity это ваши сущности (посты, клиенты, заказы). Repository позволяют изолировать логику хранения данных. На каждую сущность создаем репозиторий, который будет иметь зависимость от ApiClient (а лучше от интерфейса клиента) через DI. Основная идея репозиториев впоследствии безболезненно переходить на другие способы хранения/получения данных, поэтому следует создать для них интерфейсы и сделать реализацию этих интерфейсов для API. В Service описываем бизнес логику, используем репозитории. Контроллеры оставляем тонкими — получение сервисов и вызов их методов. Можно пойти дальше и взаимодействие сервисов перенести в специальные сервисы. Это полезно, если потребуется использовать данную логику в других частях приложения, например, в командах

Надеюсь, ответил на все вопросы. Если что-то неясно, спрашивайте

Comments

[Евгений Ромашкан]

Анемичная модель - антипаттерн. При нейминге не нужно ориентироваться на техническое значение вещей а то обычно у любителей сервисов все как на картинке только с приставкой service.

[Евгений Самсонов]

Евгений Ромашкан, C таким же успехом можно писать, что rich model это антипаттерн. И тот и другой подход применим для определенных задач и у каждого есть свои проблемы и преимущества. Именовать можно как угодно, никто не заставляет добавлять приставки service/manager/repository

[Евгений Ромашкан]

Евгений Самсонов, "Анемичная модель хороша для своих задач" это что-то из серии "сейчас накидаем mvp потом перепишем".

C таким же успехом можно писать, что rich model это антипаттерн

Нет. Если вы отказываетесь признавать low coupling/how cohesion и прочие SOLID'ы - ну, увы.

[Евгений Самсонов]

Евгений Ромашкан, вы похоже начитались умных слов, но не понимаете, что они означают. Простите, у меня не времени, чтобы тут с вами спорить и что-то доказывать :)

[Евгений Ромашкан]

Евгений Самсонов, На том и сойдёмся.

Answer 2

[Евгений Ромашкан]

Вопрос написан сумбурно и не понятно. Какая решается задача - не ясно совсем.

1. Можно ли каждую сущность представить сервисом?

Нужно разобраться с терминологией "сущность представить сервисом" - каша какая-то. Сущность это сущность, сервис это сервис.

Как получать данные для таких сущностей?

"Получать данные для сущностей" это, опять же, каша какая-то. Пишите гейтвей к апишке и грузите данные.

Service/PostService.php

И нормально именовать тоже нужно учиться. PostService - ни о чём, что делает класс - не ясно.

Создал отдельный сервис ApiService.php

Снова название ни о чём.

от которого наследуются сервисы которым нужно получать данные из api.

Наследование - выпилить и забыть как страшный сон. Экземпляры API - клиента через DI поставлять в те классы, где он нужен.