跳到内容

容器构建工作流程

编辑此页

与依赖注入组件相关的文件和类的位置取决于你想使用容器的应用、库或框架。查看在 Symfony 全栈框架中容器是如何配置和构建的,将帮助你了解这一切是如何结合在一起的,无论你正在使用全栈框架,还是希望在另一个应用中使用服务容器。

全栈框架使用 HttpKernel 组件来管理从应用和 Bundle 加载服务容器配置,并处理编译和缓存。即使你没有使用 HttpKernel,它也应该给你一个关于在模块化应用中组织配置的一种方式的概念。

使用缓存的容器

在构建之前,内核会检查是否存在容器的缓存版本。内核有一个 debug 设置,如果为 false,则存在缓存版本时会使用缓存版本。如果 debug 为 true,则内核检查配置是否为最新,如果是,则使用容器的缓存版本。如果不是,则从应用级配置和 Bundle 的扩展配置构建容器。

阅读 转储配置以提高性能 以了解更多详情。

应用级配置

应用级配置从 config 目录加载。加载多个文件,然后在处理扩展时合并。这允许为不同的环境(例如 dev、prod)使用不同的配置。

这些文件包含参数和服务,这些参数和服务按照 使用配置文件设置容器 直接加载到容器中。它们还包含由扩展处理的配置,如 使用扩展管理配置 所示。这些被认为是 Bundle 配置,因为每个 Bundle 都包含一个 Extension 类。

使用扩展的 Bundle 级配置

按照惯例,每个 Bundle 都包含一个 Extension 类,该类位于 Bundle 的 DependencyInjection 目录中。当内核启动时,这些类会注册到 ContainerBuilder。当 ContainerBuilder编译 时,与 Bundle 的扩展相关的应用级配置将传递给 Extension,后者通常也会加载自己的配置文件,通常来自 Bundle 的 Resources/config 目录。应用级配置通常使用 Configuration 对象 进行处理,该对象也存储在 Bundle 的 DependencyInjection 目录中。

允许 Bundle 之间交互的编译器通道

编译器通道 用于允许不同 Bundle 之间的交互,因为它们不能在扩展类中影响彼此的配置。主要用途之一是处理标记的服务,允许 Bundle 注册服务以供其他 Bundle 拾取,例如 Monolog 日志记录器、Twig 扩展和 Web Profiler 的数据收集器。编译器通道通常放置在 Bundle 的 DependencyInjection/Compiler 目录中。

编译和缓存

在编译过程从配置、扩展和编译器通道加载服务后,它会被转储,以便下次可以使用缓存。转储的版本然后在后续请求期间使用,因为它更有效率。

包括代码示例在内的本作品根据 Creative Commons BY-SA 3.0 许可获得许可。
目录
    版本