正确的实例化Zend_Session_Namespace和Config的方法

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() ），因此如果应用程序的每个页面都不需要活动会话，您可以考虑避免在全局启动会话。 bootstrap或插件。 在这种情况下，当他正在做的时候从控制器开始一个会话很好，所以我会说这不是坏习惯。

如果会话是在引导级别开始，但有从其他数据或因为它需要在特定的时间到期，或者只能提供这么多跳隔离某个会话数据的需要，那么它也蛮好用Zend_Session_Namespace在个人控制员。

关于获取配置，我发现使用没有问题

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

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

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