0

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

$session     = new Zend_Session_Namespace('crSession');

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

其次，他也在很多地方抓取配置文件。有时像这样：

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

或这个

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

这让我大吃一惊，因为如果我们想改变它或改变开发，我们必须改变 10 个文件。是否有任何场景需要在控制器和模型上的多个方法中发生上述实例化？

谢谢你的帮助。

4

1 回答 1

2

我认为在控制器中使用Zend_Session_Namespace. 如果您的应用程序没有在引导程序中启动会话，那么可以通过创建一个新的Zend_Session_Namespace.

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

如果会话在引导级别启动，但需要将某些会话数据与其他数据隔离，或者因为它需要在某个时间到期或只能用于这么多跃点，那么Zend_Session_Namespace在个人中使用也可以控制器。

关于获取配置，我认为使用没有问题

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

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

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

于 2012-08-04T17:38:55.653 回答