Как разделить функционал приложения по ролям?

Question

[Владимир Сингхтлов]

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

Answer 1

[Сергей Попов]

Для этого у Laravel есть такая штука, как Policies. Рекомендую внимательно, впредь, читать документацию на предмет различного функционала.

Comments

[Владимир Сингхтлов]

Ещё раз прочитай, а потом пиши чушь...

[Сергей Попов]

Владимир Сингхтлов, Я еще раз прочитал. И не вижу проблемы. Вам не кажется, что если вопрос не понят, то проблема в вопросе. Я понял его так: у вас проблема с тем, что вы не можете организовать допуски ролей к различным методам и контроллерам.

[Владимир Сингхтлов]

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

[Сергей Попов]

Владимир Сингхтлов, То есть вы хотите продублировать функционал для каждой роли? Приведите мне пример, когда для каждой роли требуется свой контроллер.

[Владимир Сингхтлов]

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

[Сергей Попов]

Владимир Сингхтлов, Давайте объективно.
Действие одно и то же, верно? Обновление записи. Даже правильнее не так: обновление записи есть запись в базу данных нового значения. Разве оно может быть разным? Нет, не может.
Единственное, что может отличаться - выбор тех вещей, которые допустимы для обновления для каждой из ролей. Но эта часть уже вполне легко читается и пишется.

[Владимир Сингхтлов]

Сергей Попов, я задал конкретный вопрос и считаю, что так будет правильней в данном случае, но у вас найдется 100 причин не ответить.
В данном случае проверить один раз и указать на конкретный контроллер будет проще, чем контролировать разрастающийся функционал в рамках одного метода. Я не просто так поднял этот вопрос, бывший сотрудник в одном методе наплодил кучу свичей и дополнительных проверок и в этой каше в 200-300 строк разбираться нет желания. Лучше 3-4 контроллера и один абстрактный класса с общими методами.

[Сергей Попов]

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

Если будет больше информации по коду - скажу более конкретно. Пока так.