Question

我在一个新的网络应用程序上工作了一个月左右。我有一个开发人员在处理很多后端的东西，而我做所有的前端编码和一些后端。该应用程序正在使用Zend Framework。我现在正在审查他的代码，因为我发现他的很多选择都不是最优的。我注意到的一些关键事项是他在很多控制器中实例化会话对象

$session     = new Zend_Session_Namespace('crSession');

这种情况发生在几个不同控制器的各种方法中。这是好习惯吗？是不是只需要一次？有一个简单的用户身份验证系统，没有任何级别或任何东西。

其次他也在很多地方抓住配置文件。有时是这样的：

$config    = Zend_Registry::get('config');

或者

$config  = new Zend_Config_Ini(APPLICATION_PATH.'/configs/application.ini', 'production');

这令我难以置信，因为如果我们想要改变它或改变为开发，我们必须更改10个文件。是否有必要在控制器和模型上的多种方法中进行上述实例化？

感谢您的帮助。

Answer 1

我认为使用Zend_Session_Namespace在控制器中实例化会话的方式没有任何问题。如果您的应用程序没有在引导程序中启动会话，则可以通过创建新的Zend_Session_Namespace在应用程序中的任何其他位置启动该会话。

启动新Zend_Session时会产生额外的开销（远远超过session_start()被调用），因此，如果您的应用程序的每个页面都不需要活动会话，您可以考虑避免在引导程序或插件中全局启动会话。在这种情况下，当他正在做的时候从控制器开始一个会话很好，所以我会说这不是坏习惯。

如果会话在引导程序级别启动，但是需要将某些会话数据与其他数据隔离，或者因为它需要在特定时间到期或者只能用于这么多跳，那么在单个控制器中使用Zend_Session_Namespace也没关系。

关于获取配置，我发现使用

没有问题

$config = Zend_Registry::get('config');

整个申请。我在引导程序中猜测配置文件被解析为一个对象或数组，然后放入注册表进行全局访问。假设引导程序使用正确的配置（生产，开发）加载了配置，那么这可能是使您的配置可用于应用程序的任何其他部分的最简单方法。

但是，我确实同意你指出的第二种方法（使用完整路径和硬编码的生产值重新解析配置）可能并不好。在我看来，所有这些实例都应该用前一段代码替换（除非有一个特定的原因，他需要生产配置中的特定值，无论应用程序当前是如何运行的。）