Zend 框架 - 当路由器需要访问会话时在哪里初始化会话答案

【问题标题】：Zend framework - Where to Initialize session when the router needs access to itZend 框架 - 当路由器需要访问会话时在哪里初始化会话
【发布时间】：2010-07-09 17:23:57
【问题描述】：

我在一个经常使用会话的项目中工作。我们有一个数据库处理程序（Zend 的标准处理程序），目前我在 preDispatchLoop 的插件中有这个初始化（数据库处理程序 + 会话启动）。以前它在 preDispatch 中，但由于每个操作都会调用它（包括“转发”操作中的那些，它给我带来了问题。

我的问题是我开始从事国际化工作，并开始使用路由器来检测 URI 中的语言：我们使用 /language/controller/action 形式）。路由器想使用会话来读取/存储语言。但正如您可能知道的那样，首先出现的是路由器，然后是（前/后）调度程序。

所以问题是：为什么不将会话初始化移至引导程序？这是因为它以前就在那里，但我不得不移动它，因为我需要测试数据库（记住会话使用数据库）是否可以访问以防止错误。如果出现错误，我只需重定向（request->setController/setAction 错误）。如果我将会话初始化代码移回引导程序，如果数据库不可访问，我将无法进行重定向。

我已经阅读了其他问题，我发现很多人要求从引导程序访问请求对象。但他们都说：你可以但不应该。但是，在这种情况下我该怎么办？我的最后一个选择是将会话初始化移回引导程序，如果失败，手动发送标头并读取视图但错误代码，但这是一个可怕的黑客攻击。

我的想法是不应该那么早使用会话。不应在引导过程中调用它们，因为它们尚未完全了解请求的控制器/操作。我认为要获得语言，我可以简单地依赖 cookie（手动）并从那里（以及从 URI）获取它。如果最终有一天会话信息必须在引导中使用，我将使用全局变量。

你怎么看？我控制应用程序的方式有错误吗？

看到的一些问题：

Zend Framework: Getting request object in bootstrap

Best way to deal with session handling in Zend Framework

（Zend 版本 1.9.6，不使用 Application 或 Bootstrap）

【问题讨论】：

不清楚为什么不能引导数据库，然后是会话，然后是路由。如果数据库不可访问，为什么需要会话来重定向？
因为如果我有错误我不能重定向。我无法直接访问引导程序中的请求对象，虽然我可以得到它，但我不应该得到它（这就是我读过的所有内容）。这就是为什么我将数据库（和会话）初始化代码移动到插件中，以便能够在错误时重定向。但是这些插件只有在路由器之后才会被调用（参见framework.zend.com/manual/en/zend.controller.basics.html 的流程）。我不需要会话来重定向错误。最后我所做的只是停止在引导中使用会话信息。

标签： session zend-framework router bootstrapping

【解决方案1】：

我会将会话初始化和数据库连接移至引导程序。
如果您在 bootstrap 期间无法连接到您的数据库，这应该算作低级错误。在生产中也不例外。
只需将引导过程包装到 try catch 块中，即可输出错误页面。

// in your index.php
try {
    $application = new Zend_Application(
        APPLICATION_ENV,
        APPLICATION_PATH . '/configs/application.ini'
    );

    $application->bootstrap()
                ->run();

} catch (Exception $e) {
    header('Content-type: text/html; charset=utf-8');
    header('HTTP/1.1 503 Service Unavailable');
    header("Retry-After: 3600");
    // Output some error page.
    echo "<html><head><title>System Error</title></head><body>...</bod></html>";
?>

【讨论】：

谢谢。我还认为 db 和 session 应该属于引导，但是在引导文件（或任何包含的文件）中发送标头和回显不是显示错误页面的“Zend 方式”。而且我们没有（直接）访问能够进行重定向的请求。我有一个带有日志记录、发送电子邮件和一个漂亮视图的错误控制器，在那里调用它，我只是想让它成为“Zend 方式”。我认为这是先有鸡还是先有蛋的问题。
我也使用错误控制器、登录等。但是有些错误你不能在“Zend Way”中优雅地捕捉和处理，因为它们看起来很早。考虑一下您的 application.ini 是否不可读。你的应用程序现在做什么？所以无论如何都需要低级处理。