Сигналы Django против переопределения метода сохранения

Question

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

def Review(models.Model) 
    ...fields... 
    overall_score = models.FloatField(blank=True) 

def Score(models.Model) 
    review = models.ForeignKey(Review) 
    question = models.TextField() 
    grade = models.IntegerField() 

Обзор является несколько «очков», то overall_score среднее из оценок. Когда обзор или оценка сохранены, мне нужно пересчитать среднее значение total_score. Сейчас я использую метод переопределенного сохранения. Будут ли какие-либо выгоды от использования диспетчера сигналов Django?

Answer 1

Сохранение/удаление сигналов в целом благоприятны в ситуациях, когда вам необходимо внести изменения, которые не являются полностью конкретными для рассматриваемой модели, или могут применяться к моделям, которые имеют что-то общее или могут быть настроены для использования через моделей.

Общепринятая задача в переопределенном методе save - автоматизированная генерация пули из некоторого текстового поля в модели. Это пример того, что, если вам нужно было реализовать его для ряда моделей, выиграло бы от использования сигнала pre_save, где обработчик сигнала мог бы взять имя поля slug и имя поля для генерации пули из , Как только у вас будет что-то подобное, любые расширенные функциональные возможности, которые вы вводите на место, также применимы ко всем моделям - например, глядя на слизню, которую вы собираетесь добавить для типа модели, о которой идет речь, для обеспечения уникальности.

Многоразовые приложения часто используют использование сигналов - если функциональность, которую они предоставляют, может применяться к любой модели, они обычно (если это не неизбежно) не хотят, чтобы пользователям приходилось напрямую изменять свои модели, чтобы извлечь выгоду из Это.

С django-mptt, например, я использовал pre_save сигнал для управления набором полей, которые описывают структуру дерева для модели, которая собирается быть создана или обновлено и pre_delete сигнала, чтобы удалить детали структуры дерева для объекта и все его поддерево объектов перед ним, и они удаляются. Из-за использования сигналов пользователям не нужно добавлять или изменять методы save или delete на своих моделях, чтобы сделать это управление для них, они просто должны позволить django-mptt знать, какие модели они хотят, чтобы они управляли.

Answer 2

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

Answer 3

Это своего рода денормализация. Посмотрите на это pretty solution. Определение поля на месте.

Answer 4

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

Answer 5

Вы спросили:

Будет ли какое-либо преимущество использования сигнала диспетчера Джанго?

Я нашел это в DJANGO документы:

методы Переопределенные модели не называются на массовых операций

Обратите внимание, что метод удаления() для объекта не обязательно называется при удалении объектов в массовом порядке с использованием QuerySet или в результате каскадного удаления .Чтобы обеспечить выполнение индивидуальной логики удаления, вы можете использовать сигналы pre_delete и/или post_delete, используя .

К сожалению, при создании или обновлении объектов не существует обходного пути, так как ни один из save(), pre_save и post_save не вызвал .

От: Overriding predefined model methods