Flask 中的设计决策

显式的应用对象

一个基于 WSGI 的 Python web 应用必须有一个中央的可调用对象来实现实际的应 用。在 Flask 中，这是一个 Flask 类的实例。每个 Flask 应用 必须创建一个该类的实例，并传给它模块的名称，但是为什么 Flask 不自己这么 做？

当不是像下面的代码这样使用一个显式的应用对象时:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def index():
    return 'Hello World!'

看起来会是这样:

from hypothetical_flask import route

@route('/')
def index():
    return 'Hello World!'

这样做有三个主要的原因。最重要的一个是，显式的应用对象需要在同一时刻只存在 一个实例。有许多方法来用单个应用对象来仿造多个应用，像维护一个应用的栈一样， 但这会导致一些问题，这里不会赘述。现在问题是：什么时候一个微框架在同一时刻需 要至少一个应用？一个很好的例子是单元测试。当你想要测试什么的时候，创建一个 最小化的应用来测试特定的行为非常有用。当应用对象删除时，它分配的一切都会被 再次释放。

当你的代码中有一个显式的对象时，继承基类（ Flask ）来更改 特定行为将成为可能。如果基于一个不暴露给你的类的对象在你之前创建，这么做只 能通过 hack 。

此外， Flask 依赖于一个那个类的显式实例还有一个非常重要的原因是：包名称。无 论何时你创建一个 Flask 实例，你通常传给它 __name__ 作为包名。 Flask 依赖 这个信息来正确地加载相对于你模块的资源。在 Python 对反射的杰出支持下，它可 以访问包来找出模板和静态文件存储在哪（见 open_resource() ）。当前显然有许多框架不需要任何配置，且能载入相对于你应用的模块的模板。但 是它们需要为此使用当前工作目录，一种非常不值得信赖的决定应用在哪的方式。当 前工作目录是进程间的，而且如果你想要在同一个进程中运行多个应用（这会在你不 知道的一个 web 服务器中发生），路径会断开。更可怕的是：许多 web 服务器不把 你应用的目录，而是文档根目录设定为工作目录，但两者不一定是一个文件夹。

第三个原因是“显明胜于隐含”。那个对象是你的 WSGI 应用，你不需要记住别的东西。 如果你想要应用一个 WSGI 中间件，只需要封装它（虽然有更好的方式来这么做来不 丢失应用对象的引用 wsgi_app() ）。

此外，这个设计使得用工厂函数来创建应用成为可能，这对单元测试和类似的东西 （ 应用程序的工厂函数 ）十分有用。