深入 Flask 源码理解 Context

知乎问题 编程中什么是「Context(上下文)」 已经能够简单地说明什么是 Context,它是一个程序需要的外部对象,类似于一个全局变量。而这个变量的值会根据提供的值而改变。
Flask 中有分为请求上下文和应用上下文:

对象 Context类型 说明
current_app AppContext 当前的应用对象
g AppContext 处理请求时用作临时存储的对象
request RequestContext 请求对象,封装了Http请求的内容
session RequestContext 用于存储请求之间需要记住的值

Flask 分发请求之前激活程序请求上下文,请求处理完成后再将其删除。

Flask 中的 Context 是通过栈来实现。


Flask 的 Context 实现

Flask 的核心功能依赖于 Werkzeug 库。

_app_ctx_stack & _request_ctx_stack

这两种栈定义在 flask/global.py 中。

首先需要了解一下 Werkzeug 中关于 LcoalStack 的相关内容。

Local

Local 是定义了一个 __storage__ 字典,其中的键为 threadid 值。

LocalStack

LocalStack 则内部维护一个 Local 实例。主要的作用是将 Local 维护的 __storage__ 字典中键为 __ident_func__() 对应的值定义为 {"stack" : [] }

LocalProxy

LocalProxy类是一个代理类,应用到设计模式当中的代理模式。简单地讲,我们不需要去了解当前的环境,而直接去操作这个 Proxy 类,这个 Proxy 类会将所有的操作反馈给正确的对象。

request & RequestContext

Flask 源码中关于 request 的定义:

从源码可以看出,request_request_ctx_stack 栈顶元素的一个属性。实际上 _request_ctx_stack 栈中的元素是 ReuqestContext 对象的实例, 而 ReuqestContext 中包含了 request 请求的所有信息,包括 Session 信息。

这里传入的 app,就是 Flask 的程序实例。
RequestContext 实例的创建在 Flask 类方法中。

Flask 中 Request 对象继承了 Werkzeug 中的 Request 对象。
上述代码涉及到 WSGI,它强调 Appication 必须是一个可调用对象。
后期的工作之一是了解 WSGI

Session

在 session.py 文件中定义了 有关Session的内容。Flask 中 Session 是构建在 Cookie 上面的。其中定义了关于 Session 的接口。

如下代码则是 session 的应用。

sessionRequestContext 中属性,所以代理说明如下:

current_app & g

一般来讲, 在 Flask Web 开发时, Flask的实例是延迟创建的。也就是说 AppContext还没有压入 _app_ctx_stack 中,所以我们在编写代码时,是无法获取完整的 Flask 实例的属性。而当用户访问时,程序的实例已经初始化完成了,因此我们采用 current_app代理获取当前 app。这仅仅是我的个人理解。实际上这是解决 多个 Flask 实例运行的问题

current_app是获取 _app_ctx_stack 栈顶 AppContext实例元素的代理.

flask.g 是存储一下资源信息的,如数据库连接信息。更多应用的则是体现在 Flask 扩展当中。

上述代码存在一个疑问是 g 对象是基于请求的,每次请求都会重置。那么 g 为什么不是 RequestContext 而是 AppContext ?
flask.g API 文档 中说明了 g 变量的改动。

1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部