0

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

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

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

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

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

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

看到的一些问题：

Zend 框架：在引导程序中获取请求对象

Zend Framework 中处理会话的最佳方式

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

4

1 回答 1

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>";
?>
于 2010-07-26T07:41:33.007 回答