SP
грубо говоря "сделать это под опенсурс" это месяц работы (в самом простом варианте), а сделать для себя - дня 3-4
Size: a a a
2020 December 16
SP
просто за счет того что оч много допущений к тому "как че у нас организовано и какие мы хотим ограничения".
ST
Добрый день. А что делать с даннвми, которые появятся после создания агрегата? Например, создаем Company ($name, $inn, $postAddress) - каталог компаний. У каждой Company есть набор услуг Services (надо, конечно, придумать другое название), которые потом должны заполняться пользователем. Отдельно от Company услуги существовать не могут, бессмысленно, но на момент создания Company, мы еще не знаем какие услуги будут. Делать так Company ($name, $inn, $postAddres, ?Services $services = null) или при создании Company в хендлере создавать еще и отдельную сущность Services с company_id с пустыми значениями? $company = new Company (
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
ST
С одной стороны не хочется делать анемичной, с другой, просто превращать в набор CRUD
ПГ
Приветствую. Подскажите плиз, как лучше.
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
MG
Добрый день. А что делать с даннвми, которые появятся после создания агрегата? Например, создаем Company ($name, $inn, $postAddress) - каталог компаний. У каждой Company есть набор услуг Services (надо, конечно, придумать другое название), которые потом должны заполняться пользователем. Отдельно от Company услуги существовать не могут, бессмысленно, но на момент создания Company, мы еще не знаем какие услуги будут. Делать так Company ($name, $inn, $postAddres, ?Services $services = null) или при создании Company в хендлере создавать еще и отдельную сущность Services с company_id с пустыми значениями? $company = new Company (
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
> Отдельно от Company услуги существовать не могут, бессмысленно - почему? Пошив одежды делают многие, почему это не может тогда этот тип услуги быть в принципе? И уточни вопрос “а что делать с данными?” - использовать
ST
> Отдельно от Company услуги существовать не могут, бессмысленно - почему? Пошив одежды делают многие, почему это не может тогда этот тип услуги быть в принципе? И уточни вопрос “а что делать с данными?” - использовать
По услугам, я не совсем правильно отписал. Услуги не могут существовать отдельно от Company. Пошив одежды делается только в Company
АГ
Приветствую. Подскажите плиз, как лучше.
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
звучит как класс и объект соответственно. что такое "шаблон адреса", почему это сущность? есть разные шаблоны адресов? ну тогда наверное под каждый шаблон по сущности надо
ПГ
звучит как класс и объект соответственно. что такое "шаблон адреса", почему это сущность? есть разные шаблоны адресов? ну тогда наверное под каждый шаблон по сущности надо
Да, шаблон - это адрес который может сохранить пользователь, чтобы потом заного не вводить, а заполнить поля 1 кликом
g
Да, шаблон - это адрес который может сохранить пользователь, чтобы потом заного не вводить, а заполнить поля 1 кликом
Шаблон не получается правилом валидации?
ПГ
Шаблон не получается правилом валидации?
Не понял ...
g
Не понял ...
Это я неправильно понял смысл "шаблона")
g
Не понял ...
Как crud-мэйкер выбрал бы вариант 3
ПГ
Как crud-мэйкер выбрал бы вариант 3
Ок, спасибо за ответ :)
АГ
в общем это чото типа "сохраненный адрес"
АГ
но я думаю в таком случае нужна таблица адресов, и айдишники этих адресов в разные места, где они нужны уже конкретно.
AN
Подскажите, что почитать про модели согласованности?
eventual consistency и тд
eventual consistency и тд
П
Привет. Как называется подход когда js клиент сидит в одном контейнере с сервером и когда каждый в своем?
ПГ
но я думаю в таком случае нужна таблица адресов, и айдишники этих адресов в разные места, где они нужны уже конкретно.
Это все понятно, что есть адреса и на них референсы где надо. Вопрос как отделить "Шаблоны" от "Адреса доставки".
SP
Павел
Привет. Как называется подход когда js клиент сидит в одном контейнере с сервером и когда каждый в своем?
никак?) Ну то есть, в чем подход то? кто файлики сервит? Есть какой "изоморфный JS" где и бэк и фронт один и тот же код юзают, и есть "обычный"... но что-то мне подсказывает что твой вопрос про другое