我已经为一个新的web应用程序工作了一个月左右。我有一个开发人员在做很多后端工作，同时我做所有的前端编码和一些后端。该应用程序正在使用Zend框架。我现在正在仔细检查他的代码，因为我发现他的很多选择都不是最佳的。我注意到的一些关键事情是，他在许多控制器中实例化了会话对象
$session = new Zend_Session_Namespace('crSession');
这种情况发生在几个不同控制器的各种方法中。这种做法好吗？不应该只要求一次吗？有一个简单的用户身份验证系统，没有级别或任何东西。
其次，他还在很多地方获取配置文件。有时是这样：
$config = Zend_Registry::get('config');
或者这个
$config = new Zend_Config_Ini(APPLICATION_PATH.'/configs/application.ini', 'production');
这让我难以置信，因为如果我们想改变这一点或改变开发，我们必须改变10个文件。在控制器和模型上的多个方法中是否有必要进行上述实例化？
谢谢你的帮助。
使用Zend_Session_Namespace在控制器中实例化会话的方式没有任何问题。如果您的应用程序没有在引导程序中启动会话，则可以通过创建新的Zend_Session_Namespace在应用程序的其他任何位置启动会话。
启动新的Zend_Session时会产生额外的开销（不仅仅调用session_start()），因此，如果应用程序的每个页面都不需要活动会话，则可以考虑避免在引导程序或插件中全局启动会话。在这种情况下，从控制器开始会话是很好的，所以我认为这不是一个糟糕的做法。
如果会话是在引导级别启动的，但需要将某些会话数据与其他数据隔离，或者因为它需要在特定时间过期或仅可用于如此多的跃点，那么在各个控制器中使用Zend_Session_Namespace也是可以的。
关于获取配置，我认为使用没有问题
$config = Zend_Registry::get('config');
在整个应用程序中。我猜在引导程序中，配置文件会被解析为一个对象或数组，然后放在注册表中进行全局访问。假设引导程序使用正确的配置（生产、开发）加载了配置，那么这可能是使配置可用于应用程序的任何其他部分的最简单方法。
然而，我同意您指出的第二种方法（使用完整路径和硬编码的生产值重新解析配置）可能不好。在我看来，所有这些实例都应该用前一段代码替换（除非有特定的原因，无论应用程序当前如何运行，他都需要生产配置中的特定值）。