Adel Раз мы определились, что работа с ролями, это бизнес-логика, тогда слой работы с БД не должен содержать в себе такую логику. Окей. Так-же мы имеем еще 2 слоя: слой аутентификации и сервисный слой. Выходит, что сервис пользователей (а потом еще трех таблиц) будет делать одинаковые запросы на выборку (обращаться к репозиторию) для разных ролей? То есть 3 репозитория, которые не относятся к пользователю, будут иметь абсолютно одинаковый код на выборку :) Хоть ты тресни, но DRY засел во мне очень плотно ))

Ну и 3 сервиса тоже будут иметь одинаковые проверки отличающиеся только объектом в рантайме ))

Ну и 3 сервиса тоже будут иметь одинаковые проверки отличающиеся только объектом в рантайме ))

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

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

Текущий авторизованный пользователь API относится к слою работы с базой данных или нет? Спрашиваю с целью, куда засунуть проверки ролей текущего пользователя, чтобы сократить объем выборки из таблиц (не все всем дозволено видеть, в отличие от админа).

it depends

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

на уровне работы с базой - например что бы добавлять в условия можо тебе или нельзя иметь доступ к данным (404 вместо 403 что бы ты даже не зал о существовании того с чем тебе нельзя работать)

на уровне приложения - например простенький RBAC, на уровне бизнес логики (когда у тебя бизнес правила посложнее чем просто роль)

не зацикливайся на слоях и все будет проще. слои не важны

одна и та же "фича" может вовлекать в себя разные аспекты инфраструктуры и бизнес логики и тут все будет только о том как фичу разделить так что бы SRP соблюдалось. А оттуда уже и слои так или иначе формироваться будут

но не пытайся думать в терминах persistence layer, domain или application layer

но не пытайся думать в терминах persistence layer, domain или application layer

Почему нельзя думать о разделении слоев в рамках таких терминов ?

Летят двое на воздушном шаре... Унесло их, и не знают, где они сейчас... Пролетают мимо холма, на котором сидит человек. Храбрые воздухоплаватели спрашивают его: - Скажите, пожалуйста, где мы сейчас находимся? Человек на холме долго думает, после чего отвечает: - На воздушном шаре. Более пожилой и, следовательно более умудренный опытом воздухоплаватель говорит другому: - Этот человек на холме - математик. - Почему же? - Он долго раздумывал над простым вопросом, после чего дал абсолютно точный и совершенно бесполезный ответ...

Извини, Фесор :)) но это сейчас про тебя. у человека довольно точно описанная проблема. а ты сильно абстрактно описал "решение"

Почему нельзя думать о разделении слоев в рамках таких терминов ?

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

Извини, Фесор :)) но это сейчас про тебя. у человека довольно точно описанная проблема. а ты сильно абстрактно описал "решение"

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

это как "валидацию данных" обощать, есть валидность пользовательского ввода, есть консистентность стэйта приложения, есть бизнес правила и бизнес логика

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

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

но он сомневается

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

я вполне конкретный ответ дал - it depends

и дальше описал что и как depends

математик :)

может ты просто не шаришь?)

ну бля, вопрос "куда положить код" - ответ "раздели его и положи штуки в свои слои"

ну и про конкретный вопрос ты загнул - он тоже абстрактный.

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

короч, ебитесь сами)

)))

короч, ебитесь сами)

Охуенное решение проблемы :D

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

Вполне конкретно. Я приводил же пример с агентами :) Задача тоже ясна - ограничить выборку данных в зависимости от роли :)

Вполне конкретно. Я приводил же пример с агентами :) Задача тоже ясна - ограничить выборку данных в зависимости от роли :)

отталкиваться надо от причин для изменения. если тебе эти 20 ВСЕГДА будут меняться одинаково.. то нет проблем. можно и в репозитории засунуть и как-то отрефакторить, чтобы было в одном месте.

конкретно в репозиторий логичнее критерий передавать явно

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

ну бля, вопрос "куда положить код" - ответ "раздели его и положи штуки в свои слои"

Да и зачем размазывать по всем слоям выборку данных в зависимости от бизнес правил? В одном месте сделал и ты молодец. Не?

Но слои тут не причем. Слои не папки, в них код не ложат

Но слои тут не причем. Слои не папки, в них код не ложат

а кладут?

Да и зачем размазывать по всем слоям выборку данных в зависимости от бизнес правил? В одном месте сделал и ты молодец. Не?

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

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

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

Это типичный Laravel, с его Auth::user() с доступом до текущего юзера. Я как правило тащу текущего юзера через DI из конструктора. Ну а вопрос “Кто знает роль?”, — и был моим вопросом в самом начале )) Кто должен её знать и где её применять? Я склоняюсь к тому, чтобы не мешать репозитории с проверкой прав доступа. > Хочешь ли ты давать глобальный доступ к сессии или же хочешь решения принимать на уровень выше и дергать что надо у репозитория? Не важно, что я хочу, важно, как правильно сделать.

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

в один файл все, как лет 10-15 назад, без классов :D

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

+

roquie (0) увеличил репутацию Aleh Kashnikau (1)

о_О

Это типичный Laravel, с его Auth::user() с доступом до текущего юзера. Я как правило тащу текущего юзера через DI из конструктора. Ну а вопрос “Кто знает роль?”, — и был моим вопросом в самом начале )) Кто должен её знать и где её применять? Я склоняюсь к тому, чтобы не мешать репозитории с проверкой прав доступа. > Хочешь ли ты давать глобальный доступ к сессии или же хочешь решения принимать на уровень выше и дергать что надо у репозитория? Не важно, что я хочу, важно, как правильно сделать.

попробуй подумать в чем правильность. Что должно быть в итоге? какие характеристики? Что проще сделать что сложнее сделать. Правильно это баланс между "усилия что бы сделать" и "гибкость". Действия я бы закрывал RBAC-ом на уровне контроллеров, доступ к данным на чтение - добавлением каких-то критериев на уровне декоратора к сервисам которые у тебя за выборки отвечают. Дальше вопрос что ты юзаешь. например - ты юзаешь active record скорее всгео причем и на запись и на чтение. это уже "не очень гибко" но возможно тебе для твоих задач хватает

ну то есть слишком много "а как у тебя реализовано то-то"

Все доступы до экшенов контроллеров ограничены с помощью authorize() в FormRequest’ах. А там ларавел сам проверяет. Сейчас задача иного плана, не просто ограничить доступ до метода, а ограничить выборку у ряда методов, в зависимости от того, какая роль у пользователя.

Для работы с базой используется Eloquent (AR) завернутый в репозитории, чтобы было проще тестить прилогос без базы (и с этим я успешно справляюсь).

Вот спрашивается, куда запихнуть проверку ролей, когда: 1. Если они в репозиториях, тогда копипаста будет все равно (только треитами и ифами размазывать) 2.Если делать в сервисах на каждый объект репозитория, тогда ловлю ту проблему, ссылку на которую я скидывал. @Adelf32 говорит, что так норм.

Для работы с базой используется Eloquent (AR) завернутый в репозитории, чтобы было проще тестить прилогос без базы (и с этим я успешно справляюсь).

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

Вот спрашивается, куда запихнуть проверку ролей, когда: 1. Если они в репозиториях, тогда копипаста будет все равно (только треитами и ифами размазывать) 2.Если делать в сервисах на каждый объект репозитория, тогда ловлю ту проблему, ссылку на которую я скидывал. @Adelf32 говорит, что так норм.

И во всех случаях чертов копипаст, который “копипастом не является”. Но руки чешутся его привести к одному варианту )

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

да)

Почти да. Критерии не динамические, они руками прописываются в коде.

Почти да. Критерии не динамические, они руками прописываются в коде.

раскрой мысль

Тут смотря что понимать, под словами “динамические критерии”. Возможно мы об одном и том-же.

ERROR: S client not available

where( ownedBy(user), premiumGoods() )

например

Ну как, сам запрос в базу будет делать выборку записей с ограничением по user_id и/или с доп. айдишниками пользователей которые ему принадлежат. Типичная выборка клиентов Агента в корпоративном мире. И все это зависит от определенной роли.

Ну как, сам запрос в базу будет делать выборку записей с ограничением по user_id и/или с доп. айдишниками пользователей которые ему принадлежат. Типичная выборка клиентов Агента в корпоративном мире. И все это зависит от определенной роли.

есть такой паттерн - Specification.

ты можешь просто генерить разные обьекты-критерии. и отдавать "репозиториям"

Ну как, сам запрос в базу будет делать выборку записей с ограничением по user_id и/или с доп. айдишниками пользователей которые ему принадлежат. Типичная выборка клиентов Агента в корпоративном мире. И все это зависит от определенной роли.

ну вот что зависит? как меняется запрос?

есть такой паттерн - Specification.

у AR есть скоупы еще для похожих вещей (композиция условий)

есть такой паттерн - Specification.

Угу. В данном случае, он мало чем будет отличаться от Criteria, который часто используют вместе с Repository. Прада, если так сделать, ты туда сможешь вынести только повторяющиеся методы (запросы) в каждом репозитории. Тогда по этой части удастся избежать копипаста.

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

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

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

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

типа...

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

Тогда ты влазишь в слой работы с базой данных :)

Тогда ты влазишь в слой работы с базой данных :)

еще не влажу

пока это критерии, описания, они не относятся к персистенсу. это лишь штуки которые делают внутри new SomeOtherCriteria(), new ByUser()

Criteria over Criteria's?

Критерия содержит в себе методы модели, чтобы сделать более узкую выборку. Методы модели и есть нечто иное, что работает с БД. Разве это не так?

да типа композиция критерий которая на основе входящих параметров выбирает что композировать

А это мысль.

Не успею я сегодня уже реализовать этот вариант, так что @Adelf32 @fes0r @mkusher спасибо за помощь :) Может чуть позже напишу о результатах.

Есть какой-нибудь паттерн, что то типа фабричного метода, только где конкретные фабрики возвращают не конкретный объект, а абстрактный (типо есть только один класс, который всегда возвращается этими фабриками, разница только в логике формирования этого класса)

конкретно порождающий нужен

ты можешь в креаторе возвраащать не абстрактный класс а конкретный и даже final

тогда получится то что ты хочешь как раз

Есть какой-нибудь паттерн, что то типа фабричного метода, только где конкретные фабрики возвращают не конкретный объект, а абстрактный (типо есть только один класс, который всегда возвращается этими фабриками, разница только в логике формирования этого класса)

фабрика или фабрика + строитель.