ИЛ
Не, мьютекс на минималках)
function handler($request, $next) {
return DB::transaction(function() use ($request, $next) {
return $next($request);
})
}Size: a a a
2020 April 22
ИЛ
почем нет, вполне норма, хотя момент спорный:
А что если у меня запрос без БД?
ИЛ
Вешать мидлу на роут? Тогда проще обернуть в слой транзакции какой-то сервис
J
Vyacheslav Prokosa
он принимает объект класса
Этот код нельзя будет запустить там где нет класса реквеста. Например в job-ах или других сервисах
J
почем нет, вполне норма, хотя момент спорный:
function handler($request, $next) {
return DB::transaction(function() use ($request, $next) {
return $next($request);
})
}жесткая текучка слоев
RK
эта строчка мне стоила 5 лет изучения фреймворка в которые входили 2 года практики (1-2 бесплатной), а вы мне скопом наслушавшись хрен знает кого доказываете что это плохо, хотите спорить покажите код который это делает лучше, только с хорошей точки зрения
VP
Этот код нельзя будет запустить там где нет класса реквеста. Например в job-ах или других сервисах
а данные ты как валидировать будешь?
VP
или пустишь туда и помо на гуще гадать будешь
ИЛ
эта строчка мне стоила 5 лет изучения фреймворка в которые входили 2 года практики (1-2 бесплатной), а вы мне скопом наслушавшись хрен знает кого доказываете что это плохо, хотите спорить покажите код который это делает лучше, только с хорошей точки зрения
Так стоп
ИЛ
Я ща рассмотрел код. А почему не проще через юзера создать пост
ИЛ
$user->posts()->create([])
AB
валидировать надо данные только от пользователя, а они проходят через слой контроллера, в джобах то не надо их валидировать, так что в сервис лучше не передавать объект реквеста
ИЛ
Не факт, что создающийся пост создан текущим юзером
ИЛ
Например мы импортируем посты из экселя по очередям
J
Vyacheslav Prokosa
а данные ты как валидировать будешь?
Валидация - в отдельном сервисе. Который вызывается из реквеста или джобы
VP
валидировать надо данные только от пользователя, а они проходят через слой контроллера, в джобах то не надо их валидировать, так что в сервис лучше не передавать объект реквеста
ой нет, это уже проходили, будешь ты парсить данные с гугл таблиц например
EG
эта строчка мне стоила 5 лет изучения фреймворка в которые входили 2 года практики (1-2 бесплатной), а вы мне скопом наслушавшись хрен знает кого доказываете что это плохо, хотите спорить покажите код который это делает лучше, только с хорошей точки зрения
для Observer модели, это "д....о"
для Event, напрмер UserGreatePost в который будете передан Post и User его создавший норам, но Auth это перебор
для Event, напрмер UserGreatePost в который будете передан Post и User его создавший норам, но Auth это перебор
J
Есть и пакеты для этого
RK
потому что через апи уже аутентифицированный пользователь создает пост, и нет никакого смысла проверять какой он там, он уже вошел и проверен, мы просто подставляем его айди перед вставкой в бд
ДК
Ром ты ток опрос снова не делай банить тебя или нет 😅