но там чуть другие штуки

Ага, а в адрес что бы - будем через геокодер яндекса прогонять каждый раз, наверное ;)

Ага, а в адрес что бы - будем через геокодер яндекса прогонять каждый раз, наверное ;)

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

или города если сеть большая

Ага, а в адрес что бы - будем через геокодер яндекса прогонять каждый раз, наверное ;)

можешь скачать базу у geonames, штукарь баксов стоит всего или даже меньше

ты я так понял вообще VO не делаешь никогда?

с такой логикой

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

Почему, я VO и у пользователя делаю ;)

будешь делать сущностью или VO?

Почему, я VO и у пользователя делаю ;)

то есть ты сделаешь историю адресов коллекцией VO?

или ты просто юзаешь VO в контексте юзеров? типа там UserProfile?

Конечно, зачем мне 10 сущностей с одним адресом

но это в случае ручной отработки адреса, если используется адресный справочник - тут связь и там и там

Конечно, зачем мне 10 сущностей с одним адресом

и будешь это хранить как jsonb поле в таблице с юзерами?

но это в случае ручной отработки адреса, если используется адресный справочник - тут связь и там и там

я бы не делал связь в любом случае

юзеры отдельно, заказы отдельно, адресный справочник отдельно

у всего есть идентификаторы мне их хватает

если исчезнет адрес - заказ исчензуть не может

если исчезнет юзер - заказ не исчезнет

они живут своими жизнями и никак не пересекаются

гормония и low cooupling/high coheasion

Адрес может поменяться. Например, меняется подчинение города, переименовывается область и т.п. В итоге у тебя в таблице заказов будут невалидные адреса

Адрес может поменяться. Например, меняется подчинение города, переименовывается область и т.п. В итоге у тебя в таблице заказов будут невалидные адреса

если у тебя есть справочник, то ты у ордера будешь уже хранить идентификатор адреса из справочника и тогда все клево

Ага, и адрес будет уже сущностью ;)

более того, адрес будет храниться вне контекста юзера или ордера

мы можем копию хранить на всякий но это не обязательно

будет подсистема для работы с адресами

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

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

баланс счета в банке это совокупность транзакций

а коды валют никогда не меняются, тут я тебе немного соврал

меняется курс

курс запоминается на момент транзакции если речь идет о транзакции обмена

нет "транзакции обмена", есть списание с одного счета в одной валюте и зачисление на другой счет в другой валюте ;)

нет "транзакции обмена", есть списание с одного счета в одной валюте и зачисление на другой счет в другой валюте ;)

это будет одной записью в лэджере и там будет вся инфа о курсах

так сделано почти во всех системах с которыми я работал во всяком случае

мне понравился пример по поводу VO vs Entity. Есть у тебя две стодоллоровые банкноты. Тебе чаще всего плевать какую из них принять в оплату. Это просто значения. Но если ты монетный двор то тебе важны идентификаторы каждй банкноты и ты их между собой различаешь.

Если ты делаешь VO 100 USD и у тебе нужен курс для отображения - сколько это в EUR, то USD и EUR по сути начинают являться индентификаторами

Привеет всем

'statisticLink' => $request->getHost() . '/api/statistic/' . $link->getTiny(),

есть такая байда в одном из методов контроллера. /api/statistic/ - это роут соответсвующий одному из методов того контроллера. Могу я его ка кто получить чтобы не хардкодить?

если делать вопрос более общим, можно ли получать роуты контроллера в виде строки?

можешь заинжектить роутер

из него по айди дергать роут

можешь заинжектить роутер

Не понял что ты называешь роутером?

класс стандартный симфоневский?

$container->get('router')->generate('some_route_name', ['foo' => 'bar']);

Что-то вроде такого

https://stackoverflow.com/questions/34678737/symfony2-get-route-path

бля ну все равно отсается хардкодд)

тогда уж в константу вынести проще

url в константу? Дык а роутинг для чего тогда?

я сокращаю ссылку, и возвращаю ответом линк на сокращенной версии и линк со статистикой переходов

и сокращенная версия и статистика переходов это роуты привязанные к определенным экшнам контроллера

$response = new JsonResponse([ 'tinyLink' => $request->getHost() . '/' . $link->getTiny(), 'statisticLink' => $request->getHost() . '/api/statistic/' . $link->getTiny(), ]);

то есть я хочу /api/statistic/ получать динамически и добавлять параметр к ней

то есть я хочу /api/statistic/ получать динамически и добавлять параметр к ней

а сделать отдельно сервис для генерации links?

Если ты делаешь VO 100 USD и у тебе нужен курс для отображения - сколько это в EUR, то USD и EUR по сути начинают являться индентификаторами

нет

а сделать отдельно сервис для генерации links?

так там все равно забивать хардкодом получается эти значения придется

и еще далше выносить их из контроллера

так там все равно забивать хардкодом получается эти значения придется

а чего ты хочешь добиться?

а чего ты хочешь добиться?

я хочу чтобы я вот решил поменять префикс с /api/ на /restapi/

и мне не пришлос везде менять это

я хочу чтобы я вот решил поменять префикс с /api/ на /restapi/

class Router { public function statisticsLink(Request $request, Link $link) { return sprintf(“%s/api/statistics/%s”, $request->getHost(), $link->getTiny()); } }

или class Router { const PREFIX = “api” public function statisticsLink(Request $request, Link $link) { return sprintf(“%s/%s/statistics/%s”, $request->getHost(), self::PREFIX, $link->getTiny()); } }

ERROR: S client not available

Привет всем. Использование gethostbyname внутри сущности Server - это плохо?

public function detectIp(): string { return gethostbyname($this->host); }

инфраструктура внутри слоя бизнес-логики?

Server - сущность?

да

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

ip может меняться

Ну тут смотря чего добиться хочешь

Красиво/некрасиво такой себе критерий

Захочешь например кастомный резолвер+свой кеш к нему, создашь интерфейсик и дабл диспатчем прокинешь

Пока нет проблемы, возможно не стоит ее решать)

да, проблемы нет

инфраструктура внутри слоя бизнес-логики?

это имеет место или нет?

в данной реализации

это имеет место или нет?

Скорее всего да, но вопрос в границах инфраструктуры. В каком-то отдалении идшник в сущносте это тож инфраструктурная деталь

если id не родной)

Вопрос скорее хочешь ли ты от этой детали абстрагироваться

если id не родной)

Родной ид в пхп это ссылка на объект

ну пока не хочу

родной для сущности

типа isbn для Book

А, ну такое да)

не суррогатный

Ага

@mkusher а как опеределить границы инфраструктуры? это исходя из предметной области?

@mkusher а как опеределить границы инфраструктуры? это исходя из предметной области?

Да, по сути ты из предметной области выкидываешь второстепенные детали, которые бизнесу непринципиальны

Это в идеальном случае

Всем привет. Юзал ли кто кэш второго уровня доктрины ?

А так добавляются еще твои потребности в данный момент

Всем привет. Юзал ли кто кэш второго уровня доктрины ?

ну юзаем