мне нужно сформулировать мысль в итоге. А то она пока у меня витает

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

пасиб

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

Да тупо всё даже в читабельность упирается

AuthController - это понятно. Логично

UserController - не понятно

https://meduza.io/quiz/ruby-ili-perl-ugadayte-yazyk-programmirovaniya-po-kodu 9 из 10 )

чет я с котлином обломался

а я попутал свифт с в обжект-с. и (о позор мне!) тупанул на репле. смутило то что посчитал что в перле регулярки в кавычках должны быть

не, перл я узнал )

а вот котлин чертовски похож на пхп )

скорее на джавку

а вот котлин чертовски похож на пхп )

+

https://medium.com/@kamerk22/the-smart-way-to-handle-request-validation-in-laravel-5e8886279271

Чувак говорит о том что задача контроллера это получить реквест и отдать респонс. Даже валидация в контроллере нарушает принцип SRP

Вру. Не тейлор

Чота с блога Тейлора попал на статью. Но все равно согласен )

А Тейлор оказывается людей нанимает на работу о_О

так для валидации есть реквесты которые передаются в контроллер. если не прошел валидацию по реквесту то и перекинет назад (или отдаст ошибки в ответе если аяксом запос был). так что все норм по логике

так для валидации есть реквесты которые передаются в контроллер. если не прошел валидацию по реквесту то и перекинет назад (или отдаст ошибки в ответе если аяксом запос был). так что все норм по логике

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

тут спорное утверждение

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

Чем спорное? Тем что я изолированно не смогу без контроллера функционал протечтировать

А если вынесу эту логику куда то, то смогу

ну так многие же пишут по принцыпу "что не запрещено - разрешено" и по тому что им так удобно )

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

@andrew_a_v это вы не про себя сейчас? :D Вас бы первого побили за секретки в коде.

@andrew_a_v это вы не про себя сейчас? :D Вас бы первого побили за секретки в коде.

да кто тут не без греха )

Ну как бы да ) Все не идеальны )

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

Смотря, какие запросы. В модель тоже не всё следует пихать.

в модель вообще ничего не стоит пихать

в модель вообще ничего не стоит пихать

что ты подразумеваешь под "ообще ничего"? а как же релейшены, скоупы, мутаторы, подключение обсервера и т.п.?

что ты подразумеваешь под "ообще ничего"? а как же релейшены, скоупы, мутаторы, подключение обсервера и т.п.?

скоуп можно вынести отдельно, как и обсерверы. релейшены, мутаторы - все.

скоуп можно вынести отдельно, как и обсерверы. релейшены, мутаторы - все.

а как вынести мутатор? в трейт?

релейшен и мутатор можно оставить

да по идее некоторую бизнес-логику вроде тоже в модели выносят, нет?

да по идее некоторую бизнес-логику вроде тоже в модели выносят, нет?

AR сам по себе это уже нарушение солид. сначала чуток логики в модель, потом глобал скоуп где-нибудь в буте, пару сеттеров, а потом в итоге ты окуеваешь от того, какая неявная магия происходит внутри

так что нет.

AR сам по себе это уже нарушение солид. сначала чуток логики в модель, потом глобал скоуп где-нибудь в буте, пару сеттеров, а потом в итоге ты окуеваешь от того, какая неявная магия происходит внутри

глобал скоупы стараюсь не юзать) лучше просто на каждый запрос явно юзать скоп, потому что так реально очевиднее. А насчет логики в модели, почему нет? $car->drive('west', 50);

я выше описал почему. потому что у меня в проекте сейчас базовый класс для всех моделей занимает 2800 строк и там такая пиздота внутри. хотя проект писали 2 синьйора как бы. пришлось просто слой моделей взять и выбросить

https://meduza.io/quiz/ruby-ili-perl-ugadayte-yazyk-programmirovaniya-po-kodu 9 из 10 )

8/10🙈

Чувак говорит о том что задача контроллера это получить реквест и отдать респонс. Даже валидация в контроллере нарушает принцип SRP

Вау, кто-то заражается хорошими практиками :) продолжай, ты в правильном пути идёшь!

я выше описал почему. потому что у меня в проекте сейчас базовый класс для всех моделей занимает 2800 строк и там такая пиздота внутри. хотя проект писали 2 синьйора как бы. пришлось просто слой моделей взять и выбросить

Что есть синьор? Они сами так себя назвали?

Всем привет. Есть задача: фильтрация клиентов с определенными параметрами и далее сохранение результатов этой фильтрации в отдельные списки клиентов. Работать этот функционал должен в двух режимах: 1. Статичный список. В этом случае понятно - просто копируем все client_id из нужной выборки и привязываем их к отдельному списку клиентов. 2. Динамический список. В этом случае результат фильтрации должен обновляться раз в несколько минут и новые клиенты, которых еще не было в сохраненном списке, должны в него сохраняться. Вопрос: как лучше сделать второй пункт? В голову приходит сохранение query builder и потом вызывать от него выборки каждые несколько минут Заранее спасибо за ответы)

даже лого откуда-то стырено. Вот точно где то видел

@perin

"Выжми из бизнеса всё", это про нашу бюрократию и налоги. А все эти книжки, так, ерунда маркетинговая )

Вау, кто-то заражается хорошими практиками :) продолжай, ты в правильном пути идёшь!

не понял твоей фразы

я этим практикам следовал еще с версии 5.0

я выше описал почему. потому что у меня в проекте сейчас базовый класс для всех моделей занимает 2800 строк и там такая пиздота внутри. хотя проект писали 2 синьйора как бы. пришлось просто слой моделей взять и выбросить

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

другая сторона медали: делать запросы к елке в контроллерах. Эта привычка побудит делать контроллеры по 2500к если проект будет расти. Технический долг начнет расти быстро

это как теория разбитых окон если кто слышал

я уже такое видел много раз. видел один контроллер в 4 тыс строк, где 6 case по 500 строк и еще куча всего ))))

я сам стараюсь представить модель как доменную модель. Это не только класс модели, но и все вспомогательные классы. богатая домменая модель как одно целое

не понял твоей фразы

Да я просто рад видеть тебя, тут в чате, судя по уровню вопросов, в основном, люди и пихают логику в контроллер и ёлку.

я сам стараюсь представить модель как доменную модель. Это не только класс модели, но и все вспомогательные классы. богатая домменая модель как одно целое

Aggregate root типа?

Да я просто рад видеть тебя, тут в чате, судя по уровню вопросов, в основном, люди и пихают логику в контроллер и ёлку.

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

Вау, кто-то заражается хорошими практиками :) продолжай, ты в правильном пути идёшь!

Меня забрызгало чьим то чсв.

Aggregate root типа?

ну нет. DDD тяжело применить. Просто лайтовая версия

как то логически с точки зрения бизнеса сгруппировать. Например Order, OrderService, OrderRepository, etc. Может не совсем по всем практикам, но это гораздо легче поддерживать чем все яйца в кучу

Меня забрызгало чьим то чсв.

Таки показалось вам, сударь. Чем больше работаю и вникаю в суть программирования, тем больше понимаю, что я ещё только в начале пути.

Народ, в таблице со статусами есть статусы с company_id = 1

Я из компании пытаюсь таким образом получить статусы для компании 2

wgereHas погугли

Ага, сейчас, спасибо

странная связь какая то

Все таки похоже что это немного не то) Мне нужно из компании с ид 2, получить статусы компании с ид 1

при жадной загрузке например у тебя не будет $this->id вообще. будет null

Тобиш релейшен примерно такой "получаем статусы текушей компании и компании с ид 1"

Хмм, а как можно по нормальному реализовать получение каких-то дефолтных данных?

Например статусов в моем случае

Тобиш релейшен примерно такой "получаем статусы текушей компании и компании с ид 1"

опять же это не будет работать при жадной загрузке. мб не стоит делать это релейшеном?

Да, наверное

определи нормальный релейшен статусов. дополнительно определи метод который будет возвращать данные релейшена (коллекцию) и мержить ее с дефолтными

Да, я понял идею. Пожалуй так и сделаю сейчас

Спасибо большое

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

кстати минутка образования: кто знает термин мемоизация? а кто не знает загуглите и будете знать)