Ух, ну да, у них такого нет. Да и не лишнее ли это, когда есть роли?

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

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

самый быстрый пример кейсов: любая CRM, sluck, группы соц сетей

1С-Битрикс тим :D

teams можно рассматривать как группы ролей. поэтому нет, не лишнее.

Да, тогда у spatie такого нет. Возможно - пока нет.

я такого вообще ещё не видел. в entrust не юзал (возможно, там есть это, я не обращал внимания)

я такого вообще ещё не видел. в entrust не юзал (возможно, там есть это, я не обращал внимания)

И я сейчас по entrust пробежал - нету там такого. Только самим ваять.

ну, надо что-то и самим делать :D

не всё фреймворк конфигурить :D

я такого вообще ещё не видел. в entrust не юзал (возможно, там есть это, я не обращал внимания)

в энтрасте есть хорошее решение по подключению прав в контроллер. Поэтому жаль что я раньше не смог подсмотреть решение

ну, зато теперь вы знаете, как правильно выбрать пакет =)

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

это я про symfony / yii 2 и прочие. laravel сильно балует разраба

Раз уж разговор зашел о коде и решении. Может кто замечания свои сказать?

Раз уж разговор зашел о коде и решении. Может кто замечания свои сказать?

1. оформлен не по psr

оформление привести в порядок, прежде всего. сейчас логику посмотрю.

1. оформлен не по psr

пробелы - переносы?

пробелы - переносы?

ага

во, норм

в нотации, если не ошибаюсь, указывают ещё название переменной

@var array

после типа

например @var array $accessRoles

это я про symfony / yii 2 и прочие. laravel сильно балует разраба

symfony это не низкоуровневый фрейм, у него просто архитектура другая, и многие bad practices в отличии от лары не поощряются, типа статических прокси (которые в ларе называются фасады), обилие хелперов которые пытаются заменить собой DI, что повышает связность проджекта, запихивание работы в очередь с помощью интерфейсов (Queueable) и прочее прочее

@var array

не указаывают если проперти класса

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

это я про symfony / yii 2 и прочие. laravel сильно балует разраба

Ну по сравнению с Yii2, как по мне, лара наоборот более "дисциплинирует" и ведет в правильных направлениях.

Symfony да, более многословен и строг

Ну по сравнению с Yii2, как по мне, лара наоборот более "дисциплинирует" и ведет в правильных направлениях.

я касался и Yii 2, и Symfony лишь кончиком мизинца левой ноги ) вот с Silex'ом работал активно. и подобные решения, где нужно писать больше на чистом php, потом могут даваться сложнее, я именно это хотел сказать )

symfony это не низкоуровневый фрейм, у него просто архитектура другая, и многие bad practices в отличии от лары не поощряются, типа статических прокси (которые в ларе называются фасады), обилие хелперов которые пытаются заменить собой DI, что повышает связность проджекта, запихивание работы в очередь с помощью интерфейсов (Queueable) и прочее прочее

А как без хелперов ? ?

так-то, вроде, норм.

если не считать больших условий. тут можно порефакторить

так-то, вроде, норм.

Меня интересует насколько корректно было использование checkAuth и callAction в контексте проверки прав?

symfony это не низкоуровневый фрейм, у него просто архитектура другая, и многие bad practices в отличии от лары не поощряются, типа статических прокси (которые в ларе называются фасады), обилие хелперов которые пытаются заменить собой DI, что повышает связность проджекта, запихивание работы в очередь с помощью интерфейсов (Queueable) и прочее прочее

Фасады да... Как по мне - сама боль(

А как без хелперов ? ?

прокидывать все зависимости в методы / контроллеры класса,вместо event юзать 'Illuminate\Events\Dispatcher', например и так далее

если не считать больших условий. тут можно порефакторить

вынести в переменную и потом в условии просто проверить переменную?

Меня интересует насколько корректно было использование checkAuth и callAction в контексте проверки прав?

это должно быть в миддлваре, не?

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

вынести в переменную и потом в условии просто проверить переменную?

тут надо подумать. мб, есть вообще лишние условия?

прокидывать все зависимости в методы / контроллеры класса,вместо event юзать 'Illuminate\Events\Dispatcher', например и так далее

Справедливо наверное. Но ни разу сам не использвал миддлвары. Судя по доке - их можно в конструктор запихать. Тогда мой класс бесполезен :)

обязательно попробуйте, это нужная вещь.

в миддлварах вся валидация должна быть.

в контроллере уже валидация логики, но не входных данных.

ок. заюзаю. ? поработать копипастером придется конечно, но не страшно ?

Пока не знаю как миддлвары ведут себя в тестах

Но узнаю ?

а я до сих пор тесты не писал под реальные проекты ) вот как раз собираюсь )

какой смысл миддлваре тестить отдельно? или контроллеры даже

кстати, вот насущный вопрос: что тестировать? говорят, что нужно тестировать всё, что может вести себя не так, как ожидается. то есть, всё, что написал сам, например, какие-то методы не из коробки.

верно ли это?

Ты сначала подумай, для чего нужны тесты, чтобы не писать тесты ради тестов

А там уже будет понятно, какие кейсы в каких местах тестировать

тесты нужны чтобы было понимание, что при очередном изменении кода текущий код не был сломан.

Я тесты пишу для а) проверки логики, б) построения архитектуры

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

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

+

+

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

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

Сервисы, Работа, кто то их Action называет )

Я тесты пишу для а) проверки логики, б) построения архитектуры

а как тесты помогают в построении архитектуры?

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

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

а как тесты помогают в построении архитектуры?

test driven development же

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

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

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

а скажи, где в таком случае долна модель быть тоже в сервисе?

? Не понял

Модель это модель

сервис это сервис

В сервисе должна идти бизнес логика

test driven development же

сперва тест, потом реализация, знаю. я думал, как-то иначе, ОК, спасибо

у тебя в статье сервис зависит от модели

и ?

https://medium.com/@remi_collin/keeping-your-laravel-applications-dry-with-single-action-classes-6a950ec54d1d

Есть ли выгода в такой архитектуре, когда есть ТОЛЬКО веб версия или только АПИ? В таком случае у нас будет по сути экш в экшене

Я или не проснулся или чет не понимаю, в чем вопрос

Ребят статья не моя )) Это пример как выносить логику из контролеров и модели

Парень в стать называет это дело Action

Я думла ты пробовал

Ребят статья не моя )) Это пример как выносить логику из контролеров и модели

а ты не знаешь хорошие проекты на гитхабе которые можно поизучать где такой подход реализован?

у него оно отличается от Jobs тем что оно может возвращать значения

Я так примерно и делаю ток я сервисами обзываю

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

Ну хоть "Беда" назови )

главное что б суть ясна была

а ты не знаешь хорошие проекты на гитхабе которые можно поизучать где такой подход реализован?

Я не пойу что тебе не ясно то ?

Я не пойу что тебе не ясно то ?

ну почему к примеру как Иван говорит не создать отдельный класс, а делать сервис и через DI прокидывать его, в чем к примеру тут профит

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

название хелпер как то не вяжется с single responsibilty принципом. когда вижу хелпер/manager классы, чаще всего оказывается что в них куча разного шлака понапихано, этакие god objects

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

Ты не понял, сервис выполняет по факту какое то действие, которое несет в себе логику

ТЫ его выносишь из Модели и Контроллера для того что б не привязываться к системе скажем так

Т.е. Сервис получает объекты и что то с ними делает и отдает какой то результат

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

Еще он спасает тебя от дублирования кода

пример

сперва тест, потом реализация, знаю. я думал, как-то иначе, ОК, спасибо

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

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