и этот самый createCache

открыли список групп-> перешли на 5ую страницу->открыли список юзеров у первой группы-> у юзера есть список групп куда он привязан-> нажали добавить новую группу-> появляется окошко с спиком всех групп и пагинация стоит на первой

открыли список групп-> перешли на 5ую страницу->открыли список юзеров у первой группы-> у юзера есть список групп куда он привязан-> нажали добавить новую группу-> появляется окошко с спиком всех групп и пагинация стоит на первой

в списке групп?

и кто стэйт ресетнул?

ты ж там что-то про redux говорил

лучше попробуй нарисовать

написать*?

у меня нету щас редакса

нет нарисовать)

до редаксов я стэйт в сервисах хранил

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

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

так, не понял. У тебя открыт список групп, и надо в модалке еще один отпрыть. так?

и там должна быть разная пагинация? или одинаковая?

разная

или во втором списке нет пагинации?

везде есть

и таких может быть 10 вложенных

ну ок, не будем пока ux темы обсуждать

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

не шарю

я код пишу книг не читаю

компонент хранит че там у него по пагинации?

я код пишу книг не читаю

что такое "состояние" шаришь?

стайт

я на реакте писал

ну это все меняет

лан мне надо код писать, харе болтать, спс за советы, пригодятся

Допустим есть User, который может подписаться на автора. Если рассматривать User как сущность с поведением, то в голову приходит такой код: class User { subscribeTo(Author author) { this.subscriptions.add(new Subscription(this, author)) } }Но требования поменялись, теперь если User не подтверждён, то он не может иметь больше трёх подписок. Где делать проверку - в сущности или в сервисе? Если в сервисе - то нужно ли дублировать эту проверку в сущности?

Допустим есть User, который может подписаться на автора. Если рассматривать User как сущность с поведением, то в голову приходит такой код: class User { subscribeTo(Author author) { this.subscriptions.add(new Subscription(this, author)) } }Но требования поменялись, теперь если User не подтверждён, то он не может иметь больше трёх подписок. Где делать проверку - в сущности или в сервисе? Если в сервисе - то нужно ли дублировать эту проверку в сущности?

где у тебя хватает для этой проверки данных?

в юзере хватает?

> он не может иметь больше трёх подписок. тот на кого подписываются?

кому нужна информация о подписках?

как она используется?

у кого ограничения

В юзере хватает данных. Неподтверждённый пользователь может подписаться только на трёх авторов. То есть достаточно if (!this.isConfirmed && this.subscriptions.count() > 2) { сообщить пользователю о том, что подписаться он не может. }Если помещать проверку в сущность, то что должен возвращать метод subscribe? Постоянно выбрасывать исключения мне не очень нравится.

В юзере хватает данных. Неподтверждённый пользователь может подписаться только на трёх авторов. То есть достаточно if (!this.isConfirmed && this.subscriptions.count() > 2) { сообщить пользователю о том, что подписаться он не может. }Если помещать проверку в сущность, то что должен возвращать метод subscribe? Постоянно выбрасывать исключения мне не очень нравится.

это исключительная ситуация?

можешь сделать метод canSubscribe() какой

но исключение чуть что кинуть надо

(или ивент, но это другая история)

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

Either)

ну то есть ты можешь статус операции если хочешь возвращать и в случае если нельзя чуваку добавлять - вернуть что все плохо

но это такое...

тут на клиентский код надо смотреть. Мне проще - у меня апишки. Если что-то идет не так - кидаю исключение и клиент сам уже рисует скрин нужный

Хорошо, спасибо за ответ. Фраза "где у тебя хватает для этой проверки данных" заставила хорошо задуматься.

почитай про "информационный эксперт"

Господа, день добрый. Вопрос - нормально ли выбрасывать эксепшены в бизнес-логике или лучше\проще возвращать что-то типа err_msg? Допустим, юзер хочет добавить какие-то данные, контроллер эти данные передает в хандлер-сервис, там они проверку не проходят. Понятно что юзеру надо об этом сказать (т.е. flash message), но на уровень контроллера бросать эксепшн или просто возвращать строку err_msg (с учетом того что это надо еще и залогировать)?

обрабочик ошибок сделай общий, чтобы стэк трйс не выплевывать всем подрят и отдавай в таком виде какой запросили, если json то отдавай json: {error:'Error text'}, html: <html>trollo с версткой сайта</html> а логируй уже со стеком

ну если ты бэк пилишь)

обрабочик ошибок сделай общий, чтобы стэк трйс не выплевывать всем подрят и отдавай в таком виде какой запросили, если json то отдавай json: {error:'Error text'}, html: <html>trollo с версткой сайта</html> а логируй уже со стеком

Понятно, что в контроллере все заворачивается в try-catch, в случае с catch я эксепшн логирую, а юзеру рендерится страница с ошибкой.

Перефразирую вопрос - когда в случае с бизнес-логикой выплевывать эксепшн, когда можно просто вернуть строку error_msg?

Ну я против эксепшенов нативных, ошибки бизнес логики 400, и жсон

Нативный тока 500)

Послушаем что другие скажут

А то как это будет выводиться уже пусть фронт решает

Ну я против эксепшенов нативных, ошибки бизнес логики 400, и жсон

Не, я не хочу рендерить 404, если есть ошибка в бизнес-логике, если он ввел некорректные данные (валидация которых проверяется несколькими запросами к бд например), то ему рендерится нормальная страница, где просто указано где-нибудь сообщение с ошибкой.

Ну 400 как раз для этого же

404 это нет данных

Ну 400 как раз для этого же

Ок, тогда как пример - юзер пытается зарегистрироваться в сервисе, но при этом уже имеет аккаунт со своим текущим ip aдресом. Бизнес-логика требует, чтобы на каждый аккаунт был уникальный ip. Мне же не выбрасывать 400 страницу в этом случае?

В моем понимании, его редиректит на главную, и выводится сообщение где-нибудь, что, мол, "по правилам 1 аккаунт = 1 ip адресс".

403 Forbidden[19] — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. 

Вот это наверное

403 Forbidden[19] — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. 

На большинстве сайтов, если юзер вводит email-адресс, который уже присутствует в бд, его же не редиректит на 403 страницу?

Господа, день добрый. Вопрос - нормально ли выбрасывать эксепшены в бизнес-логике или лучше\проще возвращать что-то типа err_msg? Допустим, юзер хочет добавить какие-то данные, контроллер эти данные передает в хандлер-сервис, там они проверку не проходят. Понятно что юзеру надо об этом сказать (т.е. flash message), но на уровень контроллера бросать эксепшн или просто возвращать строку err_msg (с учетом того что это надо еще и залогировать)?

1. на уровне контроллера стоит провести изначальную валидацию пользовательского ввода (что бы красивые месседжы были) 2. далее исключения 3. в продакшене исключения должны быть... как это не странно - исключениями. По хорошему 99% булшита должно фильтроваться еще на подходе

Ну и исключения сильно лучше тем, что легко разрулить - для веба один ответ, для API другой

1. на уровне контроллера стоит провести изначальную валидацию пользовательского ввода (что бы красивые месседжы были) 2. далее исключения 3. в продакшене исключения должны быть... как это не странно - исключениями. По хорошему 99% булшита должно фильтроваться еще на подходе

Можешь пояснить по поводу пункта 1 и 3? На примере выше, в случае с уже присутствующим ip-адресом в базе и юзером, который хочет с этим же адрессом зарегаться.

Ну и исключения сильно лучше тем, что легко разрулить - для веба один ответ, для API другой

и сильно хуже что это неявный выход из функции

Можешь пояснить по поводу пункта 1 и 3? На примере выше, в случае с уже присутствующим ip-адресом в базе и юзером, который хочет с этим же адрессом зарегаться.

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

Как изначально валидировать ip то?

вот бизнес лейер не должен ничего спрашиваьт/делать для ui

и сильно хуже что это неявный выход из функции

ну хм. не знаю

Как изначально валидировать ip то?

filter_var ip ?

filter_var ip ?

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

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

оу простите

а формат проверить это да, легко

Контроллер идет в сервис-класс с бизнес-лейером, оттуда возвращается exception, который ловится в контроллере, я правильно понял?

Контроллер идет в сервис-класс с бизнес-лейером, оттуда возвращается exception, который ловится в контроллере, я правильно понял?

зачем?

можешь просто сделать штуку которая говорит "есть такой" или "нет такого"

все сильно от задачи зависит

Мне кажется БЛ должен вернуть инфо об ошибке

Мне кажется БЛ должен вернуть инфо об ошибке

спорно

ты должен понять что пошло не так, но этого может не хватать для ui layer

зачем?

Понятно, он получает от функции в бизнес-логике true\false, и далее уже как-то показывает это в ui. Я получил ответ на свой вопрос, спасибо.

Может быть, но все завист от архитектуры и задачи, сам так же считаешь ведь