Django:信号到底有什么用处?
我很难理解信号如何在我的应用程序中工作(以及它们如何工作)。我认为它们将适用于以下三个领域(根据我目前的知识):
- 将 XML 发送到远程服务器进行报告(在事务完成后)。
- 用户上传图像后,重新调整图像大小并将缩略图上传到 S3。
- 用户从其帐户中删除图像对象后,从 S3 中删除旧图像。
我是不是完全偏离了基地(我觉得我可能是)。 我是否混淆了信号和多线程?如果是这样,它们在应用程序中进行比较吗?它们只是为了解耦吗?另外,如何确保尽早实例化它们并且不使用本地函数(因为它们会被垃圾收集)?有人可以详细说明一下吗?我是否应该将它们全部放在 request 中间件中以便我不必担心?
I have a tough time understanding how signals work into my application (and how they work period). These are three areas where I assume they would apply (with my current knowledge):
- Send XML to a remote server for reporting (after a transaction is complete).
- Re size an image and upload the thumbnail to S3 after a user uploads it.
- Delete old images from S3 after a user deletes an image object from his account.
Am I totally off base (I feel I might be). Am I getting signals and multi threading mixed up? If so, do they compare in there application? Are they only for decoupling? Also, what's the deal with making sure you instantiate them early and don't use a local function (because they'll get garbage collected)? Can someone elaborate on that? Should I put them all in request Middleware so that I don't have to worry?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
Django 信号是一种执行操作
A
以响应事件E
的方法。在虚幻世界中,您可以通过修改发生事件
E
的代码并附加执行操作A
的代码来避免使用信号。问题是,这样做会失去可维护性、可读性和许多其他软件工程形容词:)
信号允许您独立于事件
E
发生的位置或方式来执行相同的操作,因此在一种允许可维护性、可读性等的巧妙方法...是的,我认为信号对于启用解耦有用的说法确实是正确的。
(你还提到了多线程。如果你这样做是因为你认为信号很好,因为它们是并发执行的,而且速度很快......好吧......我不知道它们是否是并发执行的,但无论如何我真的不认为这是 django 信号的有用之处)
利用信号的一个好方法的例子是,当您想在 django 中向用户存储其他信息时,您必须使用用户配置文件。
在这种情况下,文档本身,告诉您,注册一个信号来响应任何新用户的创建可能会很方便,只是为了向新创建的用户添加一个空的用户配置文件。
Django Signals are a way to perform an action
A
in response to an eventE
.In a unreal world you can avoid using signals by modifying the code where the event
E
occurs and appending the code to perform the actionA
.The problem is that doing so you loose maintainability, readability and a lot of other software engineering adjectives :)
Signals allow you to do the same thing indipendently from where or how the event
E
occurs and so doing so in a clever way that allow maintanability, readability, etc...Yes, I think that saying that Signals are useful to enable decoupling is really true.
(You also mentioned multi threading. If you did so because you think signals are good because they are executed concurrently and so quickly... Well... I don't know if they are concurrently executed but anyway I really don't think this is the point for what django signals are useful for)
An example of a good way of taking advantage of Signals is about the fact that when you want to store other information to an user in django you have to use Userprofiles.
In this case, the documentation itself, tell you that it may be convenient to register a signal in response to any creation of new users just to add to the new created users an empty user profile.
这是一个可能有帮助的示例。
假设您需要在保存模型实例时执行某些操作。但是,此操作与模型或模型实例本身没有直接关系。因此,将操作代码放入模型的 save() 方法中没有什么意义。这会导致不必要的代码耦合和混乱。相反,您可以在应用程序中的其他位置(甚至在另一个应用程序中)创建更有意义的信号处理程序。
Here is an example that may help.
Suppose you need to perform some action when a model instance is saved. However, this action has got nothing to do with the model or model instance itself directly. Therefore it makes little sense to put the code for your action in a save() method on the model. It would cause unnecessary code coupling and clutter. Instead you can create a signal handler somewhere else in your application (or even in another application) where it makes more sense.
我会使用异步任务队列之类的东西来执行任务 2 和 3(图像内容),例如 Celery
这类似于多线程。
I would perform Tasks 2 and 3(the images stuff) with something like an asynchronous task queue, like Celery
That's similar to multithreading.
信号不是异步的(不以并发或并行方式运行)
这就是为什么它们对于您提到的事情不那么有用:
更好的 Celery 工作人员可以以真正异步的方式进行长期操作。
但它们在一些有限的场景中仍然很有价值
注意:由于 SQL 的生成方式,这不适用于更新查询集方法(带有保存信号)。另一个常见的混乱/错误来源。
您可以在本主题中找到这些案例及其一些示例。
Signals are NOT asynchronous (NOT running in concurrent or parallel way)
That's why they are NOT so useful for things like you mentioned:
It is better Celery workers that can do long term operations in really asynchronous way.
But they are still valuable in a few limited scenarios
Note: Due to the way the SQL is generated, this does not apply to the update queryset method (with save signals). Another frequent source of confusion/bugs.
These cases and some examples for them you can find in this topic.