Laravel - Рефакторинг разрешений пользователя "Gate :: Define" кода для упрощения чтения кода

Лично ваш существующий код в порядке. Оно работает. Это читается. Хотя по мере роста вашего приложения он может становиться более подробным, этого может и не случиться. Так зачем это улучшать?

Тем не менее, вот несколько идей. Большая часть вашего кода - это соответствие между разрешением и реализацией политики. Например, 'part.view' отображается на 'App\Policies\Parts\PartsPolicy@view. «Вес» этого сопоставления не может быть удален: его можно только перемещать.

Вы можете подумать о переносе его в более простой файл конфигурации, который выглядит примерно так:

// config/permission-map.php
<?php return [
    'post.view' => 'App\Policies\Blog\PostsPolicy@view',
    'post.create' => 'App\Policies\Blog\PostsPolicy@create',
    'post.update' => 'App\Policies\Blog\PostsPolicy@update',
    'post.delete' => 'App\Policies\Blog\PostsPolicy@delete',
    // etc...
];

Затем в загрузке вы читаете эту конфигурацию и повторяете:

// boot permissions
$permission_map = require_once('config/permission_map.php');
foreach ($permission_map as $permission => $policy_implementation) {
    Gate::define($permission, $policy_implementation);
}

Преимущество: добавление нового сопоставления политик изменяет только самую важную информацию, и вам не нужно думать о том, как сделать это сопоставление - сегодня это Gate::define, а завтра, возможно, это Sentry::policy. Кроме того, отделив данные от кода, вы можете более свободно тестировать код.

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

namespace App\Policies\Blog;

class PostsPolicy {
    /**
     * @permission post.view
     */
    public function view() { /* ... */ }
}

Я лично не фанат этого: это добавляет слой внутренней структуры, ценность которой мне трудно измерить.

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

 Permission::get()->map(function($permission){
    Gate::define($permission->slug, function($user) use ($permission){
       return $user->hasPermissionTo($permission);
    });
 });

Давайте разберем это строка за строкой

Permission::get() // Query all permissions defined in permissions database table
->map(function($permission){ // Foreach permission do the following
   Gate::define($permission->slug, // Create new gate with the permission slug
   function($user) use ($permission){
      return $user->hasPermissionTo($permission); // the user table has many to many relation with permissions table, here we only check if $user is associated with $permission
   });
});

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

Структура базы данных

1. Создать таблицу базы данных permission

2. Создать таблицу базы данных roles

3. Создать сводную таблицу базы данных permission_role

4. Создать сводную таблицу базы данных role_user

Определить отношения

1. Роль имеет множество разрешений (отношение "многие ко многим", определите это с помощью belongsToMany)

2. Разрешение принадлежит многим ролям (отношение многие ко многим, определите его с помощью belongsToMany)

3. У пользователя много ролей (отношение "многие ко многим", определите это с помощью belongsToMany)

Уменьшите количество разрешений global

Используя Gate::before, вы можете разрешить конкретному пользователю, имеющему разрешение global или root, авторизовать все определенные возможности:

Gate::before(function ($user, $ability) {
    if ($user->hasPermission('root-access')) {
        return true;
    }
});

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