请求声明周期

介绍

知道请求的生命周期非常重要，了解底层逻辑以便写出更好的软件。当你对开发工具的工作方式有了更好的了解，你将会更加自信。本文将尝试尽可能详细的解释从启动到执行的请求流程。若要阅读有关如何使用 Request 类，请阅读 Requests 。

生命周期概述

Masonite 通过 服务提供者 引导，这些服务提供者加载组件、钩子、驱动程序和其他的对象到 服务容器 ，然后开发人员可以在视图、中间件和驱动程序中调用。

不过，并不是所有的服务提供者都需要在每个请求上都运行，他们已经在恰当的时间将对象加载到了容器中。例如，不需要在每个请求上都将路由加载到容器中，因为服务一旦启动路由就不会再发生改变。

现在，服务运行（使用 craft serve 之类的）首先启动根目录下的 wsgi.py 文件。这里注册了所有的服务提供者。这意味着这些对象首先会被加载到容器中，然后被其他服务提供者使用。无论服务运行是否必须，他们都会被注册（稍后会详细介绍）。

现在，值得注意的是，服务还没运行，我们仍然在 wsgi.py 文件里创建了容器并注册了我们的服务提供者。

在注册了所有服务提供者之后，我们将服务提供者分成两个单独的列表。第一个列表是 WSGIProviders ，包含了设置 wsgi=True 的服务提供者，这也是默认的。我们将会用到这个列表中的提供者加快应用程序的速度，因为现在不需要遍历所有提供者并查看哪些需要运行。

在循环中，我们还创建了另外一个 wsgi=False 的服务提供者列表，并启动。这些提供者可能包含了诸如 Manager 类的东西，这些程序要求首先注册驱动，但是不需要 WSGI 服务器运行。

同样，更重要的是，这个时候 WSGI 也绑定到了容器中。默认行为是将 WSGI 应用程序包装在 Whitenoise 容器中，以帮助直接转发静态文件。

如果您不想使用 Whitenoise，可以通过将该服务提供者换成其他服务提供者来更改此行为。

一旦运行了所有注册方法以及 wsgi 为 false 的服务提供者的所有启动方法，容器中就有了 WSGI ，就可以使用 WSGI 的值来启动服务器。

然后，我们从容器中创建 WSGI 的实例，并将其设置为 application 应用程序变量。然后在这里启动 WSGI 服务器。

服务器

现在我们已经运行了服务器，我们为请求创建了一个新的入口点。该入口点是 bootstrap / start.py 中的app函数。

所有wsgi服务器都设置了一个称为 environ 的变量。为了使我们的服务提供者都能使用，我们将其绑定到容器中的 Environ 键。

接下来，我们运行所有其中 wsgi 为 true 的服务提供程序 (因为WSGI服务器正在运行)。

WSGI 服务提供者

现在，请求生命周期将执行所有这些服务提供程序。显然您可以在请求中的任何时间添加任何服务提供者，但 Masonite 附带5个提供者，它们应按其顺序保留。这些提供者被注释为 #Framework Providers 。因为请求需要依次击中每个提供者，所以它们应该是按顺序排列的，尽管您可以在它们之间放置任何数量的任何类型的服务提供者。

我们带着这5个服务提供者开始进入循环，它们是

App 服务提供者

该服务提供商将对象(例如路由，请求类，响应，状态代码等)注册到容器中，然后在每次请求时将环境加载到这些类中，以便它们可以随环境而变化。请记住，我们在服务器启动时首先注册了这些类，它们实际上是单例对象。已经存在的对象不会再被重新实例化，它们被实例化一次直到服务器被杀死时死亡。

Session 提供者

如果有任何中间件将请求重定向，则准备执行的视图将不会执行。

例如，如果用户想去仪表板页面，但中间件将请求重定向到登录页面，则仪表板控制器和视图将根本不会执行，将被跳过。 Masonite 在执行视图之前检查请求是否正在重定向。

同样，可以通过将 Request 参数传递到构造函数中来将请求对象注入中间件，如下所示：

from masonite.request import Request

class SomeMiddleware:

    def __init__(self, request: Request):
        self.request = request

    ...

这样在执行该中间件时，会将 Request 类注入到构造函数中。在 中间件 文档中了解中间件如何工作的更多信息。

该服务提供程序加载了使用 sessions 的功能，将 sessions 辅助工具添加到所有视图，甚至将 session 属性附加到 request 类。

路由提供者

该提供者加载路由，并响应对象，静态代码，运行中间件和其他显示特定逻辑的路由。这是逻辑性非常强的服务提供者。该提供程序通过检索路由，找到要命中的路由并执行控制器和控制器方法。

状态码提供者

该提供者负责显示您在开发和生产过程中看到的友好的HTTP状态码。该服务提供者允许将自定义HTTP错误页面放入 resources / templates / errors 目录中。

此服务提供的内容没什么特别的。如果希望它显示默认的 WSGI 服务器错误，可以将其删除。

准备响应

服务提供者收集了上述服务提供者所提供的一些类，并构造了一些诸如 content type 的 header 头，状态码，设置 cookie 和 重定向。

退出服务提供者循环

一旦将这5个提供程序执行完毕 (以及您自行添加的提供者)，我们就有足够的信息来显示输出。我们离开服务提供者循环，并设置特定于 WSGI 的响应和输出。然后输出将设置 cookie，headers 头，响应，状态码以及所有要展示的 html (或 json) 发送到浏览器。

本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://learnku.com/docs/masonite/2.3/ar...

译文地址：https://learnku.com/docs/masonite/2.3/ar...