Comments 12
Толковый пост. Статическая бизнес-логика должна быть в коде, а не в базе данных. Относится не только к PHP и Laravel, а вообще к любому фреймворку. И не только к системе прав пользователей.
Чем отличается ваш пост от этого?
Во всех этих пакетах печально то что нельзя пермишенны для анонимусов.
Хотя вроде с выходом 5.7 могло что-то поменятся.
Часто пишут по старинке. Типа, как два года назад использовал какую то стороннюю библиотеку, так и дальше на новых проектах ее продолжают использовать, несмотря на то что фреймвоорк уже предлагает лучшие решения из коробки. Но это же разбираться надо, а многим лень
Идея использование Seeder класса(пример) намного лучше.
А почему вы не расматривате вариант вынести создание ролей в миграцию? При таком подходе у всех разработчиков будет актуальное состояние данных в БД.
Это, кстати, хороший вариант :) но немного холиварный. Не по себе мне миграции использовать не для изменения структуры бд. Но, возможно, я не прав.
Сиды предназначены только для тестовых данных. Решение в виде миграция очень даже нормальное, особенно с учётом того, что альтернативой является запиливание минимального интерфейса для управления всей авторизационной кухней, даже если это просто создание новой роли.
Я юзаю миграции для подобного рода «фундаментальных» данных.
Ну… прям опровергнуть полностью ваш подход мне нечем. всякие SRP приплетать тут не очень умно наверно. Могу лишь сказать, что один из пакетов неявно рекомендует именно сиды — github.com/spatie/laravel-permission#database-seeding
Адептусы Святого Шпателя не есть истина в последней инстанции, ибо Великая Книга прямо говорит нам:
Laravel includes a simple method of seeding your database with test data using seed classes.
Могу лишь согласиться. Так написано прямо начиная с 4.2, я проверил :)
А мы в своих проектах в миграциях держали лишь структурные изменения. В сидах же лежали умные классы, которые любые старые наборы изначальных данных приводили к нужному свежему набору.
Так удобнее… поскольку сид можно было менять. а вот миграцию будь добр каждый раз создай новую.
Похоливарить можно, но нет смысла.
А мы в своих проектах в миграциях держали лишь структурные изменения. В сидах же лежали умные классы, которые любые старые наборы изначальных данных приводили к нужному свежему набору.
Так удобнее… поскольку сид можно было менять. а вот миграцию будь добр каждый раз создай новую.
Похоливарить можно, но нет смысла.
По мне, так policy за глаза хватет, когда 1 пользователь = 1 роль.
Для чего-то сложного, типа роли+права, по хорошему надо писать пакет под конкретный проект (в принципе ничего сложного), — на то и лара.
Выскажу своёё фи с точки зрения «из коробки» — из коробки оно хорошо в 2х случаях:
а) оно вписывается в архитектуру приложения и будет востребовано (основной параметр)
б) вы «буржуй» и думаете в ИХ ключе понимания строения вселенной. Поясню. Русскоговорящие (основной язык архитектора — Русский) думают несколько сложнее буржуев, так как сам язык сложнее. В следствии чего решения более простые, масштабируемые (например пакет настолько удобный, что переносится от проекта к проекту; смотрим на Сову и удивляемся её живучести), и либо используют механику (в данном случае лары) либо вообще настолько простые, что выдают требуемый результат без использования той же лары, средствами основного языка.
Как-то…
Для чего-то сложного, типа роли+права, по хорошему надо писать пакет под конкретный проект (в принципе ничего сложного), — на то и лара.
Выскажу своёё фи с точки зрения «из коробки» — из коробки оно хорошо в 2х случаях:
а) оно вписывается в архитектуру приложения и будет востребовано (основной параметр)
б) вы «буржуй» и думаете в ИХ ключе понимания строения вселенной. Поясню. Русскоговорящие (основной язык архитектора — Русский) думают несколько сложнее буржуев, так как сам язык сложнее. В следствии чего решения более простые, масштабируемые (например пакет настолько удобный, что переносится от проекта к проекту; смотрим на Сову и удивляемся её живучести), и либо используют механику (в данном случае лары) либо вообще настолько простые, что выдают требуемый результат без использования той же лары, средствами основного языка.
Как-то…
Sign up to leave a comment.
Вам действительно нужны entrust или laravel-permission для реализации вашей авторизации?