正确的方式来实例化Zend_Session_Namespace和配置

Question

我一直在一个月左右的工作一个新的Web应用程序。我有一个开发人员在处理很多后端工作，而我完成所有前端编码和一些后端。该应用程序正在使用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'); 

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

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