S)
Size: a a a
2021 April 01
AN
похоже, что только пересборкой php с флагом
но вот в чем вопрос, если не пересобирать пыху, этот +1 в пиде это же просто закономерность? существует вероятность, что какой-то другой процесс вклинится и получит этот +1?
--enable-sigchild можно пофиксить.но вот в чем вопрос, если не пересобирать пыху, этот +1 в пиде это же просто закономерность? существует вероятность, что какой-то другой процесс вклинится и получит этот +1?
Есть вероятность такая кстати
CB
Возвращаясь к вчерашнему вопросу про валидацию. Вот вам кейс:
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
VM
Возвращаясь к вчерашнему вопросу про валидацию. Вот вам кейс:
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
создавай ВО в том порядке, в каком хочешь валидировать =)
CB
Volodymyr Melko
создавай ВО в том порядке, в каком хочешь валидировать =)
в VO есть конструктор, конструктор требует в себя данные в т.ч. данные из АПИ.
Мы не хотим запрашивать данные из АПИ, если провалится валидация уникальности email
И мы не хотим искать email в базе до того, как не убедимся, что это действительно email
Мы не хотим запрашивать данные из АПИ, если провалится валидация уникальности email
И мы не хотим искать email в базе до того, как не убедимся, что это действительно email
VM
$email = new Email($emailString);
$this->checkIsUnique($email);
$apiDependantVO = new ApiDependantVO($this->getDataFromApi());
$this->checkIsUnique($email);
$apiDependantVO = new ApiDependantVO($this->getDataFromApi());
ПГ
Возвращаясь к вчерашнему вопросу про валидацию. Вот вам кейс:
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
Чет читал читал, и не понял проблемы. Логично делать сначала легкие операции. Плюс нужно смотреть по месту, на сколько какой кейс более частый или нет. Не старайтесь найти золотую кнопку. Есть множество решений, они все будут рабочими. А для бизнеса главное рабочие решения. Для архитектуры же важно чтобы можно было легко расширяться, легко читался код, легко тестировалось и при этом не оверхэдить лишний раз. Если разные методы под это все подходят - они все хороши.
CB
Volodymyr Melko
$email = new Email($emailString);
$this->checkIsUnique($email);
$apiDependantVO = new ApiDependantVO($this->getDataFromApi());
$this->checkIsUnique($email);
$apiDependantVO = new ApiDependantVO($this->getDataFromApi());
ну, дробить VO действительно вариант)
VM
ну, дробить VO действительно вариант)
VO в принципе не должно содержать много полей. По крайней мере мне трудно представить пример такого ВО
ПГ
Возвращаясь к вчерашнему вопросу про валидацию. Вот вам кейс:
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ
Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.
Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их в сущность?
При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно
^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше
Ваши мыли по этому поводу @dexplon @fes0r
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодноВот это вообще мало понятно. Почему VO должно быть проверено на уникальность в рамках логики VO
VM
телефонный номер, мыло, деньги - вот отличные примеры для ВО