• Время чтения ~1 мин
  • 20.09.2022

Модель данных — одна из самых важных частей любого приложения Laravel. Многие системы будут спроектированы вокруг этой модели данных, поэтому обычно это одна из первых вещей, к которым мы обращаемся во время разработки. Некоторые из нас занимаются этим годами и имеют хорошее представление о том, как к этому подступиться, в то время как другие, возможно, еще не привыкли к этому. Я узнал о моделировании данных до того, как узнал, что существует такая вещь, как фреймворк, проектируя свою модель данных с помощью операторов CREATE TABLE.

В этом руководстве я расскажу, как вы можете обращаться с данными. моделирование в вашем приложении Laravel - и несколько полезных советов.

Это руководство является первой частью продолжающейся серии, в которой мы должны были построить всю рабочую систему, готовую к производству, от начала до конца к концу. Другими словами, от IDE к серверу.

Что будем строить? Я рад, что вы спросили. Я мог бы сделать здесь что-то простое, например, приложение ToDo или блог, но вы не узнаете из этого ничего полезного. Вместо этого мы собираемся создать что-то уникальное и захватывающее, состоящее из довольно большого количества движущихся частей, что в конце концов должно стать чем-то стоящим. Недавно я отправился на охоту за системой бронирования конференц-залов, и, честно говоря, я изо всех сил пытался ее найти. Итак, мы будем создавать проект с открытым исходным кодом в Laravel. Цель здесь состоит в том, чтобы создать что-то, что мы ожидаем в производственной среде, и в то же время предлагать что-то бесплатно.

Что будет включено в управление этим конференц-залом Платформа? Это не будет приложение в стиле SaaS, где любой может зарегистрироваться и использовать его, это будет то, что вы загружаете и запускаете сами. На данном этапе очень важно подумать об этих решениях, поскольку они во многом определяют нашу модель данных. Инструкции по настройке можно пройти. На платформу можно пригласить общего системного администратора, чтобы он мог приглашать пользователей и настраивать систему по мере необходимости.

Let'Сначала взгляните на нашу модель User, которая не совсем такая же, как типичная модель пользователя Laravel. В конце концов, мы переделаем нашу модель пользователя в пакет, который будет управлять аутентификацией для нас -, но пока мы будем упрощать ее.

Нашей модели пользователя потребуется дополнительный столбец с именем type, который будет Enum. Мы сохраним столбец подтверждения электронной почты для более эффективной проверки пользователей в среде на основе API.

Теперь миграция пользователей должна выглядеть следующим образом:

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

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();
    });
}

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

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 внесены минимальные изменения, за исключением дополнительного заполняемого столбца и обеспечения возможности приведения свойства type к нашему Enum.

Прежде чем мы углубимся в детали, вы, вероятно, задаетесь вопросом о самом 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 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