
Bohdan
17.04.2018
12:51:56
на данный момент так
но суть не в конкретном случае

Maksim
17.04.2018
12:52:52
а в чём?) в нейминге метода?

Bohdan
17.04.2018
12:53:05
суть в обработке формы с энным количеством полей, которые ложатся под идею "edit entity" и где по ux (хотя по семантике значения, возможно, разные) нет смысла делать раздельное редактирование (по крайней мере, затраты того не стоят)
возможно, да)

Google

Bohdan
17.04.2018
12:53:09
хотя скорее
это выбор между change или update и setFoo, setBar, setBaz

Maksim
17.04.2018
12:53:56
change, имхо, от setX не особо отличается

Bohdan
17.04.2018
12:54:11
так что, вероятно, тут правды не найти

Yegor
17.04.2018
12:54:58
У меня новый блог пост, о том как быть, если проблема слишком сложная, а времени мало: http://www.yegor256.com/2018/04/17/how-to-be-lazy.html

Bohdan
17.04.2018
12:55:03
т.к. она в дальнейшем разделении сущностей

Maksim
17.04.2018
12:55:16
ну ты либо клешнями всё делаешь "как надо", либо как-то автоматически (читай, через setX)

Bohdan
17.04.2018
12:55:31

Maksim
17.04.2018
12:55:56
в смысле берёшь дтошку с формочкой и маппишь её ручками прям красиво

Bohdan
17.04.2018
12:56:42
ты ж знаешь мой кейс: у меня формочка маппится на дтошку-команду, а обработчик команды уже все дергает
ну и вот вопрос в том, что должен дергать обработчик команды)

Maksim
17.04.2018
12:57:38
ну обработчик принимает команду и "раскладывает" всё по методам) ну или не парясь рефлексией забивает)

Bohdan
17.04.2018
12:57:52
как бы пихать в сущность штуку типа updateFromCommand - фи

Google

Maksim
17.04.2018
12:57:56
у меня обработчики триггерят ивенты, поэтому чуток легче

Bohdan
17.04.2018
12:58:02
рефлексия тут - явно треш)

Maksim
17.04.2018
12:58:16
вариант от балды, сам понимаешь)

Sergey
17.04.2018
13:00:32
change(Profile::new(firstName, lastName, bla, bla)

Bohdan
17.04.2018
13:01:01
так я VO и изменяю...
точнее, embedded

Maksim
17.04.2018
13:01:25
у него просто пример некорректный)

Sergey
17.04.2018
13:01:59
можно просто попросить создать новый на базе старого
в этом плане change твой вполне валидный

Bohdan
17.04.2018
13:03:54
про иммутабельность подумаю, точно

Sergey
17.04.2018
13:04:15

Bohdan
17.04.2018
13:05:06
осталось подумать, почему embedded сущность должна быть vo

Sergey
17.04.2018
13:05:17
потому что embedded не сущность?)
потому что embedded это именно ВО?
если сомневаешься - просто попробуй изменить поле в VO
UoW не задетектит изменений (хотя тут не уверен)))

Bohdan
17.04.2018
13:07:10
ай тьфу

Google

Bohdan
17.04.2018
13:07:18
голова не ворочает
это не embedded
просто связанные сущности
но по сути - композиция
contact data, используется ещё в трех сущностях

Dmitry
17.04.2018
13:40:12
мужики, вопрос не совсем по теме, посоветуйте, пожалуйста, ресурс\ресурсы для понимания алгоритмов и структур данных. В гугле не забанили, просто инфы такое множество, а по времени не хочется распыляться

Bohdan
17.04.2018
13:40:22
грокаем алгоритмы

Roman
17.04.2018
13:44:51
Ымутабылыти

Bohdan
17.04.2018
13:46:20
голова не варит и называю штуки не их именами

Roman
17.04.2018
13:47:11

Antoine
17.04.2018
20:50:01
Ребята, привет, наставьте меня на путь истинный!
Пишу клиентов для внешних АПИ. Их много и все разные, очень часто встречается "антипатерн" когда апи отвечает с ошибкой, отказом, просит повторить запрос чуть позже.
разраб который был до меня не парился в коде либы делал в каждом методе public finction getById() { while(true) { ... sleep($s); ... } } , надо ли говорить сколько муки с таким кодом. собственно я вычистил все либы от этих while и sleep, но теперь вопрос куда лучше поместить эту логику перезапросов?
просто перемещением в клиента библиотеки лучше не становится, от перемены слагаемых местами сумма не изменяется... вот думаю может между клиентом и библиотеками сделать фасад или прокси по GoF? или какие есть хорошие практики решения таких задач?

Mykola
17.04.2018
20:51:52
есть нехорошая практика типа Phystrix, но она не спасет полностью

Bohdan
17.04.2018
20:54:45
Ребята, привет, наставьте меня на путь истинный!
Пишу клиентов для внешних АПИ. Их много и все разные, очень часто встречается "антипатерн" когда апи отвечает с ошибкой, отказом, просит повторить запрос чуть позже.
разраб который был до меня не парился в коде либы делал в каждом методе public finction getById() { while(true) { ... sleep($s); ... } } , надо ли говорить сколько муки с таким кодом. собственно я вычистил все либы от этих while и sleep, но теперь вопрос куда лучше поместить эту логику перезапросов?
просто перемещением в клиента библиотеки лучше не становится, от перемены слагаемых местами сумма не изменяется... вот думаю может между клиентом и библиотеками сделать фасад или прокси по GoF? или какие есть хорошие практики решения таких задач?
возможно, не так понял, но если есть возможность менять то, как клиенты получают задачи - можно приделать очередь задач

da horsie
17.04.2018
20:54:45

Antoine
17.04.2018
20:56:50
синхронные

da horsie
17.04.2018
20:57:07
все ли запросы нужно пытаться повторить при ошибке? подойдет ли одна и та же стратегия ко всем API?
и ко всем запросам
должна ли логика приложения управлять стратегией перезапросов?
имхо общего простого решения нету

Google

Mykola
17.04.2018
20:59:06
ну зависит

Antoine
17.04.2018
20:59:40
у всех апи/методдов разнаая логика для понимания необходимости перезапроса

da horsie
17.04.2018
20:59:57
у разных API будут разнче критерии "фатальная ошибка или можно повторить запрос"

Antoine
17.04.2018
21:00:29
у всех разная, но может совпадать у двух случайно взятых апи/методов

Mykola
17.04.2018
21:00:36
а это какой-то пхп-скрипт-по-крону?

Antoine
17.04.2018
21:00:37
т.е. сейчас копипасты очень много

Mykola
17.04.2018
21:00:42
или вебморда?

Antoine
17.04.2018
21:00:46
это в реалтайме
веб

da horsie
17.04.2018
21:00:52

Antoine
17.04.2018
21:01:25
т.е. каждый метод каждого апи должен уметь себя перезапрашивать?

da horsie
17.04.2018
21:01:44
ну типа result = fooClient.doBar(arg1, arg2, new RetryTimes(3))

Antoine
17.04.2018
21:01:45
таки хочется это вынести в отдельную сущность для упрощения

Mykola
17.04.2018
21:02:00
если таки веб, то phystix может помочь... ну или концепцию оттуда взять
там комманд-паттерн днище и еще донные зависимости от зенд-di
но в целом инструмент как раз для такого кейса
есть фолбеки и т.д.
(но я бы для своего проекта свой написал)

da horsie
17.04.2018
21:04:45
в более общем случае где-то в DIC можно делать как-то так new FooClient(new HttpClient(new RetryStrategy()))

Mykola
17.04.2018
21:05:16

Google

da horsie
17.04.2018
21:05:33

Mykola
17.04.2018
21:05:53
я не о синтаксисе

da horsie
17.04.2018
21:06:52

Егор
17.04.2018
21:06:58
видел примеры с декоратором, как по мне просто и понятно
class Api {
request()
}
class RetryDecorator {
construct(private api: Api) {}
request() {
// call this.api.request() and retry on failure
}
}

Mykola
17.04.2018
21:08:24
да, с декоратором будет красивше

Егор
17.04.2018
21:08:30
ещё есть http клиенты с поддержкой middleware и там уже всё готовое: https://github.com/guzzle/guzzle/blob/master/src/RetryMiddleware.php

Antoine
17.04.2018
21:09:29
вот кстати гузле и используется...

Mykola
17.04.2018
21:12:57
вызывать реквест в мидлваре - это дно
не делайте так

Antoine
17.04.2018
21:13:32
Phystrix будет сложно, т.к. ему нужно чтоб все запросы были от его абстрактного класса унаследованы, если я правильно понял

Mykola
17.04.2018
21:15:30
так же сложно, как и любой другой способ... ну сам фистрикс лучше не брать, но идею из него можно подглядеть

Antoine
17.04.2018
21:17:28
выглядит неплохо:
https://justcodeit.ru/povtornaya-otpravka-http-zaprosov-v-guzzle/

Mykola
17.04.2018
21:17:32
вообще, как по мне, то побеждают два решения:
- декоратор (как самый быстрый и простой вариант)
- то же самое, но без декоратора

Antoine
17.04.2018
21:18:48
декоратор, спасибо, попробую

Mykola
17.04.2018
21:21:06

Дмитрий
17.04.2018
21:42:06
Вы решаете проблему не с того конца