Как правильнее реализовать получение данных со стороннего API?

Question

[yalex1442]

Начинаю изуать ООП,фреймворки SF2, в частности.
Возник вопрос как правильнее реализовать функционал
Есть Bundle в которых контроллеры отвечают на http-запросы пользователя.

Как правильнее обращаться к сторонниму API (instagram) , прописать всю логику спросов к api прямо в http-контроллере, создать новый контроллер с вынесенными в него сметодами API или новый bundle для этого?

Как общепринято?

И еще говорят, что считается правка composer библиотеки напрямую изменяя код в vendor не хорошим, как дополнять либы новым функционалом?

UPD:
я использую эту либу для обращения у instagram, но там нет функции возвращения результатов с нескольких запросов к API, например максимальное количество фото за один вызов метода 33,( ограничение API), чтобы сразу вернуть например 100 фоток приходится городить что то подобное в контроллере

while (count($media)<100){$result+=$obj->get_media();}

поэтому возник вопрос как добавить новый функционал к классу.

как насчет создания класса потомка с доп методами?

по поводу создания сервиса, как я понял из документации сервис это
класс лежащий в директории контроллеров, с методами возвращающий данные, и никаких особых ограничений с его реализацией нет?
т .е описать подкласс с доп методами наследующий родительскую composer библиотеку правильнее в сервисе?

По поводу репозитория
Если сервис будет возвращать массив Entity Class фото со свойствами(дата загрузки, размеры, люди на фото и т.п.), получится некоторое подобие репозитория?

Answer 1

[Сергей Протько]

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

Как вы написали, контроллеры должны обрабатывать HTTP запросы, вот пусть они этим и занимаются. Берут запрос, забирают и обрабатывают данные, просят сервисы что-то сделать (а не делают сами) и потом выплевывают результат работы этих сервисов наружу.

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

Короче основная мысль, раз уж говнокодить (а на этапе обучения без этого никак не обойдешься) то пускай это дело будет изолировано за красивым интерфейсом, что бы потом можно было подправить и изменения не влияли на все приложение.

А еще было бы неплохо попрактиковать TDD но это если вам позволяет время. Вообще настоятельно рекомендую перейти на практику TDD (почитайте Кента Бэка на эту тему).

И еще говорят, что считается правка composer библиотеки напрямую изменяя код в vendor не хорошим, как дополнять либы новым функционалом?

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

Answer 2

[Алексей Павлов]

>Как правильнее обращаться к сторонниму API
Лучше всего, сделать сервис, в котором будет ваш код связи с-чем-угодно. А в самом приложении использовать сервис, как высокоуровневый элемент. Если вы видите, что этот код может в будущем будет использоваться в разных проектах, то тогда есть смысл вынести в отдельный бандл. Я не вижу большого смысла разделять один проект на разные бандлы (разве что специально сделать их очень слабо связанными).
Почитайте мой ответ в другом вопросе.

>как дополнять либы новым функционалом?
Форкнуть либу, дополнить вашим кодом, и подключать ваш форк. Это общее правило, не только для Symfony, и не только composer. Иначе, если автор библиотеки выпустит новую версию (новую функцию или исправление бага), то ваше изменение будет конфликтовать с новой версией либы.