Django 在视图之间传递数据 [英] Django Passing data between views

问题描述

我想知道在视图之间传递数据的最佳"方式是什么.创建不可见字段并使用 POST 传递它是否更好，还是应该在我的 URL 中对其进行编码?或者有没有更好/更简单的方法来做到这一点?对不起，如果这个问题很愚蠢，我对网络编程还很陌生:)

I was wondering what is the 'best' way of passing data between views. Is it better to create invisible fields and pass it using POST or should I encode it in my URLS? Or is there a better/easier way of doing this? Sorry if this question is stupid, I'm pretty new to web programming :)

谢谢

推荐答案

在视图之间传递数据有不同的方式.实际上，这与在 2 个不同脚本之间传递数据的问题没有太大不同当然也有一些进程间通信的概念.想到的一些事情是 -

There are different ways to pass data between views. Actually this is not much different that the problem of passing data between 2 different scripts & of course some concepts of inter-process communication come in as well. Some things that come to mind are -

1. GET 请求 - 第一个请求命中 view1-> 向浏览器发送数据 -> 浏览器重定向到 view2
2. POST 请求 -(如您所建议的)与上述流程相同，但适用于涉及更多数据的情况
3. Django 会话变量 - 这是最简单的实现
4. 客户端 cookie - 可以使用，但可以存储的数据量有限制.
5. 网络服务器级别的共享内存- 棘手但可以做到.
6. REST API - 如果您可以拥有独立服务器，那么该服务器可以使用 REST API 来调用视图.
7. 消息队列 - 同样，如果可以使用独立服务器，甚至消息队列也可以工作.即第一个视图 (API) 接收请求并将其推送到队列，其他一些进程可以弹出消息并点击您的第二个视图(另一个 API).这将分离第一和第二视图 API，并可能更好地管理负载.
8. 缓存 - 也许像 memcached 这样的缓存可以充当中介.但是如果有人走这条路，最好使用 Django 会话，因为它隐藏了很多实现细节，但如果规模是一个问题，memcached 或 redis 是不错的选择.
9. 持久存储 - 将数据存储在某些持久存储机制中，例如 mysql.这通过在中间放置一个数据库将您的请求(可能是面向客户端的 API)与处理部分分离.
10. NoSql 存储 - 如果写入速度处于每秒数十万的其他数量级，那么 MySql 性能将成为瓶颈(有一些方法可以通过调整 mysql 配置来解决，但这并不容易).然后考虑 NoSql DB 可能是另一种选择.例如:dynamoDB、Redis、HBase 等
11. 流处理 - 像 Storm 或 AWS Kinesis 可能是一个选项.事实上，您可以在中间使用 AWS Lambda 作为无服务器计算模块，它会读取关闭并调用您的第二个视图 API.
12. 将数据写入文件 - 然后下一个视图可以从该文件中读取(真丑).这可能永远不应该做，但把这一点放在不应该做的事情上.

1. GET request - First request hits view1->send data to browser -> browser redirects to view2
2. POST request - (as you suggested) Same flow as above but is suitable when more data is involved
3. Django session variables - This is the simplest to implement
4. Client-side cookies - Can be used but there is limitations of how much data can be stored.
5. Shared memory at web server level- Tricky but can be done.
6. REST API's - If you can have a stand-alone server, then that server can REST API's to invoke views.
7. Message queues - Again if a stand-alone server is possible maybe even message queues would work. i.e. first view (API) takes requests and pushes it to a queue and some other process can pop messages off and hit your second view (another API). This would decouple first and second view API's and possibly manage load better.
8. Cache - Maybe a cache like memcached can act as mediator. But then if one is going this route, its better to use Django sessions as it hides a whole lot of implementation details but if scale is a concern, memcached or redis are good options.
9. Persistent storage - store data in some persistent storage mechanism like mysql. This decouples your request taking part (probably a client facing API) from processing part by having a DB in the middle.
10. NoSql storages - if speed of writes are in other order of hundreds of thousands per sec, then MySql performance would become bottleneck (there are ways to get around by tweaking mysql config but its not easy). Then considering NoSql DB's could be an alternative. e.g: dynamoDB, Redis, HBase etc.
11. Stream Processing - like Storm or AWS Kinesis could be an option if your use-case is real-time computation. In fact you could use AWS Lambda in the middle as a server-less compute module which would read off and call your second view API.
12. Write data into a file - then the next view can read from that file (real ugly). This probably should never ever be done but putting this point here as something that should not be done.

想不起来了.如果我得到任何会更新.希望这在某种程度上有所帮助.

Cant think of any more. Will update if i get any. Hope this helps in someway.

这篇关于Django 在视图之间传递数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！