Question

我已经编写了几个自定义验证器和过滤器。我把它们放在图书馆里这样：

/library
    /My
        /Filter
            /FilterName.php
        /Validate
            /ValidateName.php
    /Zend
    /Zendx

我现在正在编写一个我希望“应用程序感知”的验证器。它将使用应用程序级配置值。我看到了两种可能性，每种都有自己的一套问题。

ONE ：将代码放在/application目录中。标准/推荐什么目录结构？

TWO ：将代码放在/library目录结构中。将配置选项传递给验证器的首选方法是什么？

Answer 1

冒着没有回答你的问题的风险，我通常不会像你的问题那样制作我的低级课程 - 比如过滤器和验证器 - 应用程序感知，因为我将整个应用程序提供给他们 - 配置。

相反，我尝试准确识别他们需要的app-config的哪些部分，并将这些部分作为构造函数参数传递给过滤器/验证器。

这有两个好处：

例如，假设我的自定义验证程序在执行验证时需要知道一些电子邮件地址列表以列入白名单;并且此白名单存储在application.ini config中：

whitelist[] = "good1@example.com"
whitelist[] = "good2@example.com"

并且此app-config对象存储在密钥'config'下的Zend_Registry中。

我可以使用以下方法让验证者访问该信息：

$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
// use the whitelist

但这是，IMO，太可怕了。我无法对验证器进行单元测试，因为它将配置信息从以太中拉出来。

或者，我可以将整个app配置传递给构造函数中的验证器：

$validator = new My_Validate_ValidateName($config);

至少现在，当我想测试验证器时，我可以传入不同的$config个对象/数组，并且很明显验证器依赖于某些东西。

但我认为这给验证者提供了超出他需要的信息。此外，他需要知道如何从app-config访问白名单。该信息可能因项目而异。而且，无论如何，直接看到验证者只需要电子邮件地址的白名单并不容易。

在我看来，最好的事情是：

$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
$validator = new My_Validate_ValidateName($whitelist);

现在，我很清楚验证器需要什么。他从哪里获得它无关紧要 - 从app-config，远程服务到其他任何东西。验证者的消费者有责任为验证者提供他所需要的东西。

例如，如果该验证器的使用者是表单，那么表单需要知道如何以某种方式获取该白名单。同样的原则适用：在他的构造函数中给他他需要的东西。当我最终达到控制器级别时，我认为自己处于“app-level”状态。那时，我很期待控制器知道他在哪里可以找到他的app-config以及如何访问其内部数据。

只是我自己的看法。因人而异。 ; - ）

<强>更新

至于位置，我倾向于根据预期用途放置它们。也就是说，如果我打算跨项目使用它们，那么我将它们放在library中。如果我打算仅在此应用程序中使用它们，那么我将它们放在application中。