Z
Корзина сохраняемая на бэке, но мы тогда на апи поиска навешиваем функционал (а глянь ещё вот на корзину, есть ли они уже в корзине)
Size: a a a
2021 November 13
N
А в каких кейсах корзину хранить на клиенте это ок? А то в голове сразу строится картина что на бэкенде нужно будет проверять цену и наличие товара и каким то образом этот конфликт решать в плане UX для юзера
П
Мне кажется всё зависит от конкретного ТЗ. Если предусмотрена возможность регистрации на сайте магазина, то корзину зарегистрированных пользователей можно хранить на бэке. По поводу ux не совсем понятно какие конфликты ты имеешь ввиду
SP
А без регистрации нельзя хранить на бэке?)
П
А нафига ?)
SP
Что бы бизнес знал что люди добавляют в карзину и что туда кладут и что не доходят до чекаута
N
Имеется ввиду что нужно будет юзеру выводить как то что вот эти то товары не в наличии уже, или что цена изменилась
SP
У уди про это было в if (domain logic) cqrs saga
П
А какие есть нормальные варианты идентифицировать юзера без учётки, чтоб достать его корзину ?)
Если сохранять для статистики только
Если сохранять для статистики только
SP
Куки, сессии, вот это все.
SP
Кто просит "надёжно"
SP
Вводится тайм-аут какой, если ты мол завис то пользователя явно заставить пересчитать карзину мол. Всякое можно
SP
1. Можно ли доверять клиенту что-то считать
2. Что будет если посчитают неправильно
3. Влияют ли действия других пользователей на логику
4. Подсчёты нужны только на клиенте?
5. Работа оффлайн?
2. Что будет если посчитают неправильно
3. Влияют ли действия других пользователей на логику
4. Подсчёты нужны только на клиенте?
5. Работа оффлайн?
SP
Ну тип таких
2021 November 15
ПГ
Приветствую. Подскажите плиз про паттерн Creator из GRASP. Есть код следующий по его правилам:
Что делать, следуя этому паттерну, если addOrderItem будет требовать больше 3 аргументов, т.е. явно требуется рефакторинг и выделение класса? Банально добавляем currency.
public class Order {
public void addOrderItem(int amount, String name, int price) {
orderItems.add(new OrderItem(amount, name, price));
}
}
public class OrderItem {
public OrderItem(int amount, String name, int price) {
this.amount = amount;
this.good = new Good(name, price);
}
}Что делать, следуя этому паттерну, если addOrderItem будет требовать больше 3 аргументов, т.е. явно требуется рефакторинг и выделение класса? Банально добавляем currency.
В
price+currency=money
N
Кстати можете подсказать почему советуют (вроде тот же Фаулер) всегда хранить деньги парой (количество, валюта)?
Если у нас одна валюта на все приложение? или у нас транзакции в пределах например одного магазина на маркетплейсе который сам себе валюту выставляет, и она используется чисто для вывода на фронте
Если у нас одна валюта на все приложение? или у нас транзакции в пределах например одного магазина на маркетплейсе который сам себе валюту выставляет, и она используется чисто для вывода на фронте
ПГ
Это понятно, вопрос в том, что по паттерну, нужно этот money создавать внутри Good,
А у нас будет
А у нас будет
addOrderItem(int amount, String name, int price, string currency) который нужно как то рефачитьВ
а нельзя всюду передавать вместо int price объект денег? вместо того, чтобы передавать еще и валюту и где-то внутри соединять в money?
ПГ
Так в этом вопрос паттерна и как с ним верно работать. Так можно и Good создавать снаружи и передавать. Подобно money. Но он создается внутри OrderItem