Django在视图之间传递数据 [英] Django Passing data between views
问题描述
我想知道在视图之间传递数据的最佳方式是什么。最好创建不可见的字段并使用POST传递，还是应该在我的URLS中进行编码？还是有更好/更容易的方式做到这一点？对不起，如果这个问题很愚蠢，我对网络编程很新：）
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 :)
谢谢
推荐答案
有不同的方式在视图之间传递数据。实际上这并不是两个不同脚本之间传递数据的问题，当然，进程间通信的一些概念也是如此。一些想到的东西是 -
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 -
- GET请求 - 第一个请求命中view1->将数据发送到浏览器 - >浏览器重定向到view2
- POST请求 - （如您所建议的）与上述相同的流程，但适用于涉及更多数据时
- Django会话变量 - 这是最简单的实现
- 客户端Cookie - 可以使用但是是可以存储多少数据的限制。
- 在Web服务器级别共享内存 - 可以完成。
- REST API的 - 如果您可以拥有独立服务器，那么该服务器可以使用REST API来调用视图。
- 消息队列 - 再次，如果一个独立的服务器是可能的，甚至消息队列也可以工作。即第一个视图（API）需要请求并将其推送到一个队列，而其他一些进程可以弹出消息，并触发您的第二个视图（另一个API）。这将解耦第一个和第二个视图API，并可能更好地管理负载。
- 缓存 - 也许像 memcached 可以作为调解员。但是如果一个人正在走这条路线，最好使用Django会话，因为它隐藏了很多实现细节，但是如果扩展是一个问题，memcached或者
- 持久存储 - 将数据存储在某些永久性存储机制（如mysql）中。这样就可以通过中间的数据库将您的请求与处理部分（可能是面向客户端的API）脱钩。
- NoSql存储 - 如果写入速度为在其他顺序每秒数十万，那么MySql的性能将成为瓶颈（有办法通过调整mysql配置来解决，但它不容易）。那么考虑到NoSql DB可能是另一种选择。例如：dynamoDB，Redis，HBase等。
- 流处理 - 像或 AWS Kinesis 如果您的用例是实时计算，可以是一个选项。实际上，您可以在中间使用 AWS Lambda 作为无服务器的计算模块，读取并调用您的第二个视图API。
将数据写入文件 - 然后下一个视图可以从该文件读取（真正的丑陋）。这可能永远不会做，但将这一点放在这里不应该做的事情。
- GET request - First request hits view1->send data to browser -> browser redirects to view2
- POST request - (as you suggested) Same flow as above but is suitable when more data is involved
- Django session variables - This is the simplest to implement
- Client-side cookies - Can be used but there is limitations of how much data can be stored.
- Shared memory at web server level- Tricky but can be done.
- REST API's - If you can have a stand-alone server, then that server can REST API's to invoke views.
- 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.
- 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.
- 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.
- 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.
- 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.
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屋！
