理解前端控制器、Kernel以及环境是如何一起工作的

3.4 版本
维护中的版本

如何掌握创建新环境一文中,讲解了“Symfony通过环境来配合不同的配置文件以运行你的程序”的基本知识。本节将深入解释当你的程序启动时到底发生了什么。为了能够打入到进程中,你需要理解以下“一起工作”的三个部分:

通常,你不需要定义自己的前端控制器或是AppKernel.php类,因为Symfony标准版已经提供了合理的实现。

本文意在解释“程序背后”是怎么回事。

前端控制器 

front controller前端控制器是一个很好的设计模式。它是一小段代码,可令所有 请求通过一个程序入口来执行。

Symfony Standard Edition中,此项原则被app.phpapp_dev.php两个文件用到,它们在web/目录下,是处理请求时最先执行的PHP脚本。

前端控制器的主要目的是创建一个AppKernel实例(紧跟着还要做点事),使它能处理请求并对浏览器返回相应的响应。

因为所有的请求都是通过前端控制器进入路由,因此前端控制器可以在“设置kernel”之前或是在“使用新功能decorate(装饰)内核”之前执行全局初始化。例如:

  • 配置自动加载器,或是添加附加的自动加载架构;
  • 通过把kernel和一个AppCache实例进行打包来添加HTTP级别的缓存;
  • 开启(或跳过)ClassCache
  • 开启Debug组件

下面这样的请求URL可以触发前端控制器:

1
http://localhost/app_dev.php/some/path/...

如你所见,这个URL中包含了作为前端控制器而出现的PHP脚本名,你可以使用它来切换前端控制器,或者使用一个自定义的前端控制器,只需把脚本放到web/目录即可(如:app_cache.php)。

当使用Apache时,可以使用Symfony标准版内置的RewriteRule(重写规则),你可以从URL中去除那个脚本文件名,重写规则默认使用的是app.php

几乎所有web server都可以实现上面提到的这种“重写规则”之类似行为。查看你的服务器文档以了解细节,或者参考配置Web服务器

应确保前端控制器足够安全,以防止非授权的访问。例如,你不希望在生产环境下向每一个用户提供可以使用的除错环境。

技术上讲,执行命令行时用到的bin/console脚本也是一个前端控制器,只是没有用在web上,而是用在对命令的“请求”上。

Kernel类 

Kernel类是Symfony的核心。它负责设置“组成你的程序”的所有bundles,并向它们提供程序的配置信息。然后它会在处理请求之前,使用自己的handle()方法来创建服务容器。 method.

KernelInterface接口中声明的两个方法在Kernel 中未被填实,转而作为了template methods(模板方法):

registerBundles()
它必须返回“包含有程序所需的全部bundles”的一个数组。
registerContainerConfiguration()
它加载程序级配置信息。

为了填补这些小空缺,你的程序需要Kernel的子类来实现上述方法。也就是按照约定被称为AppKernel的这个类了。

再一次,Symfony标准版提供了一个AppKernel,位于app/目录下。这个类使用了环境名称——它被传入Kernel的constructor构造方法,可以通过getEnvironment()方法—— 来决定创建哪些bundles。此处的逻辑部分就在registerBundles()方法中完成,此方法供你在给自己的程序添加bundles时进行扩展。

当然你还可以自行创建你自己的“备选或附加”的AppKernel变量。所有你需要做的,就是使你的(或新增的)前端控制器能够利用好那个新kernel。

AppKernel的名称和位置并不固定。当把多个内核置于一个单一程序中时,可能“添加附加的子目录”是有意义的,例如app/admin/AdminKernel.phpapp/api/ApiKernel.php这种。所有问题的核心在于你的前端控制器要能创建出一个合适的kernel实例。

拥有不同的AppKernels也许在开启不同的前端控制器(潜在的不同服务器上的)以独立运行你程序的不同部分(例如,admin UI,the front-end UI以及database migrations)时是有用的。

还有很多AppKernel的使用场景,比如覆写默认的目录结构。然而通过对AppKernel完成一些具体实现,毋须像上面这样大动干戈的概率也很高。

环境 

就像刚才提到的,AppKernel不得不去实现另外一个方法——registerContainerConfiguration()。这个方法负责从正确的环境中加载程序级配置信息。

Environments已经在前面章节中深度解析,你大概还记得Symfony标准版中有三种环境吧——dev, prodtest

更偏于技术的解释是,所有这些名字只不过就是从前端控制器传入AppKernel构造器的字符串。接下来这个名字会用于registerContainerConfiguration() 方法中以决定哪个配置文件将被加载。

Symfony标准版的AppKernel类通过引入app/config/config_*environment*.yml文件实现了这个方法。你当然也可以根据自己在加载配置信息时的复杂需要,以不同方式来填实这个方法。

本文,包括例程代码在内,采用的是 Creative Commons BY-SA 3.0 创作共用授权。

登录symfonychina 发表评论或留下问题(我们会尽量回复)