冒着不回答你的问题的风险,我通常不会让我的低级类——比如你的问题中的过滤器和验证器——应用程序感知,因为我向他们提供了整个应用程序配置。
相反,我尝试准确识别他们需要的 app-config 的哪些部分,并将这些部分作为构造函数参数传递给过滤器/验证器。
这有两个好处:
- 它清楚地标识了依赖关系
- 然后我可以在其他可能具有完全不同的 app-config 结构的项目上使用过滤器/验证器。
例如,假设我的自定义验证器在执行验证时需要知道一些电子邮件地址列表以将其列入白名单;并且此白名单存储在application.ini
配置中:
whitelist[] = "good1@example.com"
whitelist[] = "good2@example.com"
并且这个 app-config 对象存储在Zend_Registry
键 'config' 中。
我可以使用以下方法让我的验证器访问该信息:
$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
// use the whitelist
但是,IMO,这太可怕了。我无法对验证器进行单元测试,因为它将配置信息从以太中提取出来。
或者,我可以将整个应用程序配置传递给其构造函数中的验证器:
$validator = new My_Validate_ValidateName($config);
至少现在,当我想测试验证器时,我可以传入不同的$config
对象/数组,很明显验证器依赖于某些东西。
但我认为这给验证者提供了比他需要的更多的信息。此外,他需要知道如何从 app-config 访问白名单。该信息可能因项目而异。而且,无论如何,要直接看到验证器只需要电子邮件地址的白名单并不容易。
在我看来,最好的事情是:
$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
$validator = new My_Validate_ValidateName($whitelist);
现在,我很清楚验证器需要什么。他从哪里得到它并不重要——从应用程序配置,从远程服务,从任何地方。验证者的消费者有责任为验证者提供他需要的东西。
例如,如果该验证器的消费者是一个表单,那么该表单需要知道如何以某种方式获取该白名单。同样的原则也适用:在他的构造函数中给他他需要的东西。当我最终达到控制器级别时,我认为自己处于“应用程序级别”。那时,我很乐意让控制器知道他在哪里可以找到他的应用程序配置以及如何访问其内部数据。
只是我自己的看法。YMMV。;-)
更新
至于位置,我倾向于根据预期用途放置它们。也就是说,如果我打算跨项目使用它们,那么我将它们放在library
. 如果我打算仅在此应用程序中使用它们,那么我将它们放在application
.