Size: a a a

2021 April 11

G[

GamIet [UA, Odessa] in symfony
НЕ бизнесс-логика, это всё - что можете перенести в другой проект без изменений.
Если оно завязано на какие-то таблицы базы, специфичные для проекта, то это БИЗНЕСС -логика!
Все зависимости от того проверка это доступа и доступа на чтение или на запись.
источник

✨Basic_Instinct✨ in symfony
секунду... роли пользователя мы тоже берем из бд
источник

В

Вадим in symfony
Ну это ваше личное мнение. АбстрактКонтроллер из симфони  тоже тогда бизнеслогика, т.к. его нельзя в yii перенести
источник

G[

GamIet [UA, Odessa] in symfony
Вы про этот сценарий? что вы куда хотете записывать? в объекта поста писать список ИДов пользователей которые имеют доступ (фиганули n постов)? Правильно?
источник

G[

GamIet [UA, Odessa] in symfony
ну давайте не утрировать и говорить о переносе в рамках одного фреймфорка, ато  мы сейчас договоримся до того, что я не могу скопипастить код в C# проект, чтобы он сразу заработал, поэтому это вс1, написанное на пыхе - бизнес-логика!
источник

Ш

Шурик in symfony
бизнес-логика точно от фреймворка зависит?
источник

G[

GamIet [UA, Odessa] in symfony
нет, не зависит, где я такое говорил?
источник

В

Вадим in symfony
Нет, если оч сильно все упростить. При публикации поста читаем сколько автор уже опубликовал, и если это уже н, тоесть выполняется условие бизнес правила, то меняю флаг в обьекте юзера что ему комментарии доступны. И потом только смотрю на этот флаг, и мне без разницы кто его и как установил, если он истина значит юзеру комменты доступны
источник

Ш

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

В

Вадим in symfony
Вы начали о переносах говорить
источник

Ш

Шурик in symfony
а, не, не так, сорян
источник

Ш

Шурик in symfony
ладно, если любую логику считать бизнесовой, то любой if - это бизнес-логика
пусть будет так
источник

G[

GamIet [UA, Odessa] in symfony
лучшене флаг сохранять а кол-во опубликованных постов и сравнивать с числом, которое кочет бизнесс - ато вдруг завтра число поменяется, нужно будет всем флаги перезаписывать...
источник

G[

GamIet [UA, Odessa] in symfony
вот вы опять утрируете.
источник

G[

GamIet [UA, Odessa] in symfony
Я вас понял. Проверка доступов это НИКОГДА НЕ БИЗНЕС-ЛОГИКА!
источник

✨Basic_Instinct✨ in symfony
не утрируй))) проверка доступа мы уже говорили, может быть тупо назначение прав, и может быть наступление прав при определенном условии
источник

Ш

Шурик in symfony
проверка - нет
выдача - может быть
источник

G[

GamIet [UA, Odessa] in symfony
и и итоге мы имеем ДВА модуля, которые делают одну и ту же задачу - проверку доступа. Правильно?
источник

В

Вадим in symfony
Если поменяется, пересчитаю одним запросом. Т.к. шанс что поменяется не, н а доп условия намного больше. Например придет правило, что комменты доступны если чел опубликовал н постов за последний месяц, и тогда сохранённая цифра не имеет смысла и придется помимо логики править еще и контроллер где это проверяется
источник

✨Basic_Instinct✨ in symfony
только в одном случае есть бизнес-условие, а в друом нет
источник