Size: a a a

2020 September 24

SB

Sergei Baikin in symfony
Volodymyr Melko
в некоторых случаях да, но обычно создание дто\моделей не зло. Зло - создание сервисов
чем сeрвис отличается от DateTime?
источник

VS

Vlad Sobenko in symfony
Volodymyr Melko
намного проще, когда сервисы как чистые функции и результат их работы не зависит от внутреннего стейта, а лишь от переданных аргументов.
Конечно всеравно гдето на границах системы будут сервисы зависящие от стейта и производящие сайд эффекты, но зачем делать их там, где можно не делать
А как же Entity?
источник

DT

Dmitriy Tkachenko in symfony
Sergei Baikin
чем сeрвис отличается от DateTime?
Datetime это value object
источник

DT

Dmitriy Tkachenko in symfony
Плюс есть в стд
источник

D

Dmitry in symfony
это уже было пару недель назад 🙂
источник

DT

Dmitriy Tkachenko in symfony
Dmitry
это уже было пару недель назад 🙂
Записываешь?)
источник

D

Dmitry in symfony
Dmitriy Tkachenko
Записываешь?)
ага, память то плохая, приходится записывать
источник

D

Dmitry in symfony
впору писать FAQ чатика и закрепить, такой-то пользователь считает так-то и пошли все на
90% обсуждений сойдут на нет 🙂
источник

SB

Sergei Baikin in symfony
Dmitriy Tkachenko
Datetime это value object
как это мешает ему работать в качестве сервиса?
источник

D

Dmitry in symfony
ага, скоро перейдут к mutable immutable обьектам
источник

DT

Dmitriy Tkachenko in symfony
Sergei Baikin
как это мешает ему работать в качестве сервиса?
Никак, просто это бессмысленно. Это просто значение в обёртке. Можно и string таскать в качестве сервиса, но зачем?
источник

ПГ

Павел Г. in symfony
Sergey Protko
Cqrs имеет смысл там где конкурентный доступ к ресурсам. Где есть вероятность гонок

Event sourcing нужен там где есть процессы основанные на событиях.

Для cqrs не обязательно делать все эти шины и т.д. (особо если у тебя это будет выполняться в контексте запроса а не через очередь).

Для es cqrs обязательно в силу того как работает врайт модель (нельзя читать стэйт из врайт модели иначе получишь не консистентный стэйт)

Cqrs хорош и сам по себе, но повторюсь - тольео там где есть гонки. Иначе простой круд с table gateway подходит больше
А почему в write неконсистентный стейт? Ведь вроде он и есть самый главный источник правды.
источник

D

Dmitry in symfony
Dmitriy Tkachenko
Никак, просто это бессмысленно. Это просто значение в обёртке. Можно и string таскать в качестве сервиса, но зачем?
c iphone пишешь ?:) модно - Т9 - можно просто достало уже
источник

SB

Sergei Baikin in symfony
Dmitriy Tkachenko
Никак, просто это бессмысленно. Это просто значение в обёртке. Можно и string таскать в качестве сервиса, но зачем?
А что такое сервис? ДЛя меня это не symfony DI service например.
источник

VS

Vlad Sobenko in symfony
Dmitriy Tkachenko
Никак, просто это бессмысленно. Это просто значение в обёртке. Можно и string таскать в качестве сервиса, но зачем?
Ничего, что внутри запрашивается system time?
источник

DT

Dmitriy Tkachenko in symfony
Dmitry
c iphone пишешь ?:) модно - Т9 - можно просто достало уже
Не, ведро)
источник

D

Dmitry in symfony
Dmitriy Tkachenko
Не, ведро)
значит и там такие же правила замены 🙂
источник

VM

Volodymyr Melko in symfony
давай так. Вот есть тот контроллер, что есть и ты хочешь покрыть его тестами.
есть по сути один ифчик, значит 2 кейса. Когда юзер бот и когда не бот. + потом еще до кейс, мобайл или нет.
итого ты подготовишь 3 юзер агента для своего теста, который будут определятся как бот и мобайл или десктоп

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

вариант 2:
ты берешь нормальный сервис без внутреннего стейта и передаешь его как зависимость в контроллер
в тесте у тебя все теже 3 кейса, только не с хардкоженными юзер агентами, а с парой булевых флагов isBot\isMobile которыми ты мокаешь свою зависимость. Тесты стабильны, все довольны.

зы. маленький бонус, ваш продукт вырос, нагрузки большие и вы прикрутили свуле или что-то подобное. Стейтфул сервисы вынудят тебя ресетить контейнер на каждом запросе, иначе в сервисах останется мусор от предыдущего исполнения. Тоже самое кстати и без свуле с очередями, после каждого обработаного сообщение придется ресетить контейнер
источник

DT

Dmitriy Tkachenko in symfony
Vlad Sobenko
Ничего, что внутри запрашивается system time?
Ну другой нет штуки такой же стабильной. Трейдоффы, Трейдоффы повсюду
источник

VS

Vlad Sobenko in symfony
Volodymyr Melko
давай так. Вот есть тот контроллер, что есть и ты хочешь покрыть его тестами.
есть по сути один ифчик, значит 2 кейса. Когда юзер бот и когда не бот. + потом еще до кейс, мобайл или нет.
итого ты подготовишь 3 юзер агента для своего теста, который будут определятся как бот и мобайл или десктоп

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

вариант 2:
ты берешь нормальный сервис без внутреннего стейта и передаешь его как зависимость в контроллер
в тесте у тебя все теже 3 кейса, только не с хардкоженными юзер агентами, а с парой булевых флагов isBot\isMobile которыми ты мокаешь свою зависимость. Тесты стабильны, все довольны.

зы. маленький бонус, ваш продукт вырос, нагрузки большие и вы прикрутили свуле или что-то подобное. Стейтфул сервисы вынудят тебя ресетить контейнер на каждом запросе, иначе в сервисах останется мусор от предыдущего исполнения. Тоже самое кстати и без свуле с очередями, после каждого обработаного сообщение придется ресетить контейнер
Давай так Controller __construct(TimeInterface $time, BrowserDataInterface $browserData).
Потом new Controller(new DateTime(), new DeviceDetector($userAgent))->index($request)
источник