Что хранить в уведомлении?

Question

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

Примеры: Ваше сообщение в блоге было опубликовано. или Произошла ошибка при выполнении чего-либо. Запись была удалена.

Иногда эти модели имеют отношения типа Post → Category, и сообщение должно выглядеть следующим образом: Ваше сообщение в блоге в категории "A Category" было опубликовано.

Теперь вопросы:

• Должен ли я полностью сохранить связанную модель (например, категорию)? Это облегчило бы доступ к нему позже, но это также источник несогласованности. Или я должен просто сохранить идентификатор категории? Только сохранение идентификатора означает, что я могу ссылаться на текущие данные, но что произойдет, если категория будет удалена? Тогда уведомление не может быть предоставлено. Также мне нужно было бы также каждый раз запрашивать соответствующие модели для этого уведомления.
• Должен ли я сохранить полное сообщение или только данные и составить сообщение на клиенте? (Приложение, SPA Web-Frontend ...). Тогда как насчет локализации?

Какова лучшая практика для будущего масштабирования, а также для расширения существующих уведомлений в будущем?

Answer 1

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

Итак, давайте рассмотрим преимущества и недостаткииз обоих вариантов.

Вариант 1: сохранение, включая все данные

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

Вариант 2: сохранение, включая только ссылки

• Если связанная модель удалена, уведомление не может быть обработано (как вы упомянули).Однако я бы сказал, что в этом случае уведомление не будет иметь большого смысла.
• Если изменить связанную модель (например, изменить название категории), сообщение с уведомлением изменится вместе с ней
• Еслипозже вы захотите изменить уведомление, включив в него дополнительные поля из связанных моделей. Эти поля будут доступны

Дополнительно, если вы будете сериализовать уведомления в базе данных, вы не сможете десериализоватьих, если вы изменили модель для нее позже (например, поле было удалено).

Реализация опции 2

Чтобы перейти к варианту 2, нельзя избежать дополнительной загрузки базы данных.,

Простой способ

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

NotificationController.php

$user = App\User::find(1);

foreach ($user->notifications as $notification) {
    echo $notification->type;
}

MyNotification.php

public function toArray($notifiable)
{
    $someRelatedModel = Model::find($this->someRelatedModel_id);
    return [
        'invoice_id' => $this->invoice->id,
        'amount' => $this->invoice->amount,
        'relatedModelData' => $someRelatedModel->data,
    ];
}

Хороший путь

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

NotificationController.php

$notification = App\Notification::byUserId(1)->with('someRelatedModel);

Подробнее см. Загрузка .

Tl; drУчитывая вышеизложенное, я бы выбрал вариант 2;Сохраняйте ссылки только на те модели, которые вам понадобятся при выдаче уведомления.