AK
кстати если конфигурировать клиент то тебе и не нужно будет как-то отдельное header'ы хранить
Size: a a a
2020 October 28
С
в общем главный поинт, не нужно обращаться к глобальному стейту в твоем сервисе
а как тогда лучше многие параметры вроде lat/lon/lang/limit добавлять?
С
в конструкторе все?
AK
а как тогда лучше многие параметры вроде lat/lon/lang/limit добавлять?
через конструктор
AK
ну широту долготу нет
ЕР
Вкидывать бабки в непонятно шо и в перспективе через 40 лет оттуда шото поиметь?
Звучит как ПФР
AK
это ты уже будешь пихать когда тебе непосредственно нужно получить погоду
AK
т.е. будет что-то вроде
public function get(int $lat, int $long) { return ... }С
через конструктор
4-5 элементов в конструкторе не будем перебором?
AK
ну какие 4?
AK
у тебя большинство параметров относятся к вызову метода получения погоды, а не к конфигурации сервиса
С
у тебя большинство параметров относятся к вызову метода получения погоды, а не к конфигурации сервиса
А, понял. По факту можно limit/hours в конфигах оставить
AK
я хз что они значат, но наверное
AK
смысл имхо простой, если значение нужно постоянно и оно не меняется, то оно конфигурируется на старте приложения
С
понял-принял мысль, пожалуй да, надо так переделать. еще насчет интерфейса поверх газзла не понял мысль
AK
понял-принял мысль, пожалуй да, надо так переделать. еще насчет интерфейса поверх газзла не понял мысль
ну в конструктор будешь принимать не Guzzle\Client, а свой ClientInterface какой-нибудь
AK
или WeatherClientInterface
RV
понял-принял мысль, пожалуй да, надо так переделать. еще насчет интерфейса поверх газзла не понял мысль
не прямая зависимость
ЕР
Я написал базовый сервис для получения температуры в Москвабаде через ЯндексПогоду.
Там имеется апи, которое в таком формате примерно:
Я написал сервис:
https://github.com/forszaken/delivery/blob/master/app/Services/WeatherService.php
Где делается запрос на это апи. Параметры к запросу в отдельном методе подготавливаются, сами параметры редактируются в config/weather.php
Как можно сделать лучше, в чем минусы подхода?
Там имеется апи, которое в таком формате примерно:
GET https://api.weather.yandex.ru/v2/informers?
lat=<широта>
& lon=<долгота>
& [lang=<язык ответа>]
X-Yandex-API-Key: <значение ключа>
Я написал сервис:
https://github.com/forszaken/delivery/blob/master/app/Services/WeatherService.php
Где делается запрос на это апи. Параметры к запросу в отдельном методе подготавливаются, сами параметры редактируются в config/weather.php
Как можно сделать лучше, в чем минусы подхода?
Жесть
0. Заюзать cs fixer
1. protected поля!?
2. Тайпхинты для полей? Указание типов для полей?
3. Установку хедеров лучше в конфиг, хоть фабрику, хоть csa_guzzle какой-нить
4.
6.
7. Обращения к конфигу из класса!? Пол класса обращения к конфигу!?
0. Заюзать cs fixer
1. protected поля!?
2. Тайпхинты для полей? Указание типов для полей?
3. Установку хедеров лучше в конфиг, хоть фабрику, хоть csa_guzzle какой-нить
4.
@return mixed5. Что
get()?6.
return json_decode($response->getBody());смапить бы на DTO и вернуть её
7. Обращения к конфигу из класса!? Пол класса обращения к конфигу!?
RV
и нет вендор лока