Джанго: Для чего нужны сигналы?
Мне трудно понять, как сигналы работают в моем приложении (и как они работают). Это три области, где я предполагаю, что они будут применяться (с моими нынешними знаниями):
- Отправьте XML на удаленный сервер для создания отчетов (после завершения транзакции).
- Измените размер изображения и загрузите эскиз на S3 после того, как пользователь загрузит его.
- Удалить старые изображения из S3 после того, как пользователь удалит объект изображения из своей учетной записи.
Я совершенно не в себе (чувствую, что могу быть). Я получаю сигналы и многопоточность перепутаны? Если так, они сравнивают там в приложении? Они только для развязки? Кроме того, в чем заключается гарантия того, что вы создадите их на ранней стадии и не будете использовать локальную функцию (потому что они будут собирать мусор)? Кто-нибудь может уточнить это? Должен ли я поместить их все в запрос Middleware, чтобы мне не пришлось беспокоиться?
3 ответа
Джанго Сигналы - это способ совершить действие A в ответ на событие E,
В нереальном мире вы можете избежать использования сигналов, изменив код, в котором происходит событие E происходит и добавление кода для выполнения действия A,
Проблема в том, что при этом вы теряете удобство обслуживания, удобочитаемость и множество других прилагательных для разработки программного обеспечения:)
Сигналы позволяют делать то же самое независимо от того, где или как событие E происходит и делает это умным способом, обеспечивающим удобство обслуживания, читаемость и т. д.
Да, я думаю, что утверждение о том, что сигналы полезны для разделения, действительно верно.
(Вы также упомянули многопоточность. Если вы сделали это, потому что считаете, что сигналы хороши, потому что они выполняются одновременно и так быстро... Ну... Я не знаю, выполняются ли они одновременно, но в любом случае я действительно не думаю, что это то, для чего полезны сигналы django)
Пример хорошего способа использования сигналов - это тот факт, что, когда вы хотите сохранить другую информацию для пользователя в django, вы должны использовать Userprofiles. В этом случае сама документация скажет вам, что может быть удобно зарегистрировать сигнал в ответ на любое создание новых пользователей, просто чтобы добавить к вновь созданным пользователям пустой профиль пользователя.
Вот пример, который может помочь.
Предположим, вам нужно выполнить какое-то действие при сохранении экземпляра модели. Однако это действие не имеет ничего общего с моделью или самим экземпляром модели напрямую. Поэтому не имеет смысла помещать код вашего действия в метод save() модели. Это приведет к ненужной связи кода и беспорядку. Вместо этого вы можете создать обработчик сигнала где-то еще в вашем приложении (или даже в другом приложении), где это имеет больше смысла.
Я выполнял бы Задачи 2 и 3(графические вещи) с чем-то вроде асинхронной очереди задач, такой как Celery
Это похоже на многопоточность.
Сигналы НЕ асинхронны (НЕ работают одновременно или параллельно)
Вот почему они НЕ так полезны для вещей, о которых вы упомянули:
- Загрузка файла или пост-обработка файла
- Генерация отчетов
- Любые другие долгосрочные операции (запросы к другим серверам, ET)
Лучше, если рабочие Celery могут выполнять долгосрочные операции действительно асинхронно.
Но они по-прежнему ценны в нескольких ограниченных сценариях.
- Расширение функциональности сторонней библиотеки. Если вы используете приложение с моделями, в которых вы не контролируете код, сигналы являются более надежной альтернативой обезьяньему исправлению для выполнения определенных действий при сохранении или удалении.
- Сигналы удаления работают с методом набора запросов удаления. Если вы хотите, чтобы одни и те же действия выполнялись и при удалении одного объекта, и при удалении набора запросов, возможно, лучше всего подойдет сигнал.
Примечание. Из-за способа генерации SQL это не относится к методу набора запросов обновления (с сигналами сохранения). Еще один частый источник путаницы / ошибок. - Когда вам нужно применить один и тот же обработчик сигналов ко многим моделям. Если у вас их всего несколько, я бы предпочел переопределить метод сохранения / удаления и вызвать общую функцию. Для многих людей копирование / вставка метода сохранения повсюду становится более подверженным ошибкам, а сигналы выглядят как лучший вариант.
- Избегайте жестких зависимостей между приложениями. Если вам нужно пересечь границы приложения, особенно когда приложение может использоваться в нескольких проектах, сигналы могут быть лучше для ослабления связи между приложениями. Но будьте осторожны с этим. Используйте его, потому что вам это нужно, а не потому, что вы думаете, что вам это может понадобиться в будущем.
Эти кейсы и некоторые примеры к ним вы можете найти в этой теме.