• Час читання ~1 хв
  • 20.09.2022

Модель даних є однією з найважливіших частин будь-якої програми Laravel. Багато систем буде розроблено на основі цієї моделі даних, тому це, як правило, одна з перших речей, до яких ми підходимо під час розробки. Деякі з нас робили це роками і добре знають, як до цього підійти - тоді як інші, можливо, ще не звикли до цього. Я дізнався про моделювання даних ще до того, як знав, що існує таке поняття, як фреймворк, проектуючи мою модель даних у операторах CREATE TABLE.

У цьому підручнику я покажу, як можна підходити до даних моделювання у вашій програмі Laravel - і деякі поради щодо того, що я вважаю корисним.

Цей підручник є першою частиною поточної серії, де ми мали створити всю робочу систему, готову до виробництва, разом від початку до кінця. Іншими словами, від IDE до сервера.

Що ми будемо будувати? Я радий, що ви запитали. Я міг би зробити тут щось зрозуміле, як-от додаток ToDo або блог - але ви нічого корисного з цього не дізнаєтеся. Натомість ми збираємося створити щось унікальне та захоплююче з кількома рухомими частинами, що, зрештою, має бути чимось вартим уваги. Нещодавно я вирушив на полювання за системою бронювання кімнат для зустрічей, і, чесно кажучи, мені було важко її знайти. Тож ми створюватимемо відкритий код у Laravel. Мета тут полягає в тому, щоб побудувати щось у спосіб, який ми очікували б у виробничому середовищі, водночас пропонуючи щось безкоштовно.

Що буде включено в це управління кімнатою для нарад платформа? Це не програма в стилі SaaS, де будь-хто може зареєструватися та використовувати її, це буде те, що ви завантажуєте та запускаєте самостійно. На цьому етапі дуже важливо продумати ці рішення, оскільки це інформує велику частину нашої моделі даних.

Ми хочемо, щоб наша програма працювала, спочатку, коли це важливо, відбувається процес налаштування інструкції з налаштування можна переглянути. Загального системного адміністратора можна запросити на платформу, щоб він міг запрошувати користувачів і налаштовувати систему за потреби.

Let'Перший погляд на нашу модель користувача, яка не зовсім схожа на типову модель користувача Laravel. Згодом ми переробимо нашу модель користувача до пакету, який керує автентифікацією за нас - але поки що ми зробимо її простою.

Для нашої моделі користувача знадобиться додатковий стовпець під назвою тип, який буде Enum. Ми збережемо стовпець підтвердження електронної пошти, щоб ефективніше перевіряти користувачів у середовищі на основі API.

Міграція користувача тепер має виглядати так:

public function up(): void
{
    Schema::create('users', function (Blueprint $table): void {
        $table->id();
        $table->string('name');
        $table->string('email')->unique();
        $table->timestamp('email_verified_at')->nullable();
        $table->string('password');
 
        $table->string('type')->default(Type::ADMIN->value);
 
        $table->timestamps();
    });
}

Як ви бачите, це відносно стандартно для програми Laravel, крім додаткового стовпця, який ми хочемо додати. Звідси ми можемо почати розглядати фабрику моделей, яку нам потрібно створити для наших користувачів.

final class UserFactory extends Factory
{
    protected $model = User::class;
 
    public function definition(): array
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => Hash::make(
                value: 'password',
            ),
            'type' => Type::ADMIN,
        ];
    }
 
    public function unverified(): UserFactory
    {
        return $this->state(
            state: fn (array $attributes) => ['email_verified_at' => null],
        );
    }
 
    public function type(Type $type): UserFactory
    {
        return $this->state(
            state: fn (array $attributes) => ['type' => $type],
        );
    }
}

Ми додаємо тип за замовчуванням, який хочемо застосувати до будь-якого створеного користувача. Однак ми також створюємо допоміжний метод, щоб ми могли налаштувати тип користувача, якого ми хочемо створити.

Це веде нас до моделі та змін, які ми хочемо застосувати до неї. Є мінімальні зміни в моделі Eloquent, окрім додаткового стовпця, який можна заповнювати, і забезпечення того, що ми можемо перевести властивість типу в наш Enum.

final class User extends Authenticatable implements MustVerifyEmail
{
    use HasApiTokens;
    use HasFactory;
    use Notifiable;
 
    protected $fillable = [
        'name',
        'email',
        'password',
        'type',
    ];
 
    protected $hidden = [
        'password',
    ];
 
    protected $casts = [
        'type' => Type::class,
        'email_verified_at' => 'datetime',
    ];
}

Перш ніж ми перейдемо до більш детальної інформації, ви, мабуть, цікавитеся самим Enum і його доступними параметрами.

enum Type: string
{
    case ADMIN = 'admin';
    case OFFICE_MANAGER = 'office manager';
    case STAFF = 'staff';
}

Наша програма складатиметься з наступного:


Робочий процес для цього полягає в тому, що адміністратори запрошують офіс-менеджерів, які потім можуть розпочати адаптацію співробітників до платформи.

  • Admins; are people who are in charge of configuring the system and managing the system.
  • Office Managers; are people who have the authority to override bookings on the system.
  • Staff; are people on the system who have the ability to book the meeting rooms.

Окрім моделювання представлення даних у базі даних, нам також потрібен спосіб зрозуміти дані всередині програми. Ми можемо досягти цього, використовуючи об’єкт передачі домену, скорочено DTO.

Ми починаємо з перегляду того, що містить база даних для цієї моделі даних, а потім з’ясовуємо, що потрібно для програми . Однак час від часу нам потрібно мати можливість створювати ці об’єкти до того, як вони з’являться в базі даних.

Щоб ми могли створити чи запросити потенційного користувача чи знати щось про користувача, нам потрібен доступ до їх імені, електронної пошти та типу. Це охоплює більшість випадків використання, оскільки ресурси здебільшого ідентифікуються через зв’язування моделі маршруту.

final class User implements DataObjectContract
{
    public function __construct(
        private readonly string $name,
        private readonly string $email,
        private readonly Type $type,
    ) {}
 
    public function toArray(): array
    {
        return [
            'name' => $this->name,
            'email' => $this->email,
            'type' => $this->type,
        ];
    }
}

Тепер у нас є спосіб зрозуміти дані через базу даних і додаток. Це процес, який я повторюю в такому порядку, створюючи будь-яку програму Laravel. Це дає мені абстракцію від моделі, яку можна передати, не будучи простим масивом, але при цьому забезпечує рівень безпеки типу для властивостей. Іноді мені потрібен прямий доступ до властивостей, але не так часто, і коли це потрібно, я створюю засіб доступу замість того, щоб змінювати властивості' видимість.

Comments

No comments yet
Yurij Finiv

Yurij Finiv

Full stack

Про мене

Professional Fullstack Developer with extensive experience in website and desktop application development. Proficient in a wide range of tools and technologies, including Bootstrap, Tailwind, HTML5, CSS3, PUG, JavaScript, Alpine.js, jQuery, PHP, MODX, and Node.js. Skilled in website development using Symfony, MODX, and Laravel. Experience: Contributed to the development and translation of MODX3 i...

Про автора CrazyBoy49z
WORK EXPERIENCE
Контакти
Ukraine, Lutsk
+380979856297