Zend framework 基于实体的密钥的可读表示的适当位置

首先是一些背景。我们最近将基于Zend_Db_表的解决方案转换为基于实体的解决方案（原则）。随着应用程序的增长，表类变得越来越丑陋。一些表使用枚举列存储基于字符串的键，这些键通过静态方法转换为人类可读的字符串。大概是这样的：

public static function getProductType($productKey)
{
    if (!array_key_exists($productKey, self::$productTypes)) {
        return null;
    }
    return self::$productTypes[$productKey];
}

public static function getProductTypes()
{
    return self::$productTypes;
}

class Model_Product
{
    public static function getAllTypes()
    {
        return array(/* key-value pairs */);
    }

    //returns non human readable value
    public function getType()
    {
        return $this->_type;
    }
}

class Model_Product_Presenter
{
    protected $_model;

    public function __construct(Model_Product $model)
    {
        $this->_model = $model; 
    }

    //returns human readable value
    public function getType()
    {
        $types = $this->_model->getAllTypes();

        if (!array_key_exists($this->_model->type, $types)) {
            return null;
        }
        return $types[$this->_model->type];
    }

    public function getDateCreated($format = "Y-m-d")
    {
        return date($format,$this->_model->timestamp);
    }
}

在转向基于实体的系统时，我尽量避免使用静态方法。我将值转换键移动到视图助手中，并将其命名为“一天”。最后，我发现这是不够的，因为我们需要在JSON对象中返回它们，这发生在表示层之外（即，无法直接访问视图帮助程序）

---

有人对这些方法的合适位置有什么理论吗？我是否应该创建单独的对象来执行从键到人类可读值的转换，在实体对象上实现静态方法，或者其他什么？

我的理论是，这应该在模型本身中完成。但有时在处理复杂模型时，我喜欢创建一个单独的类来处理该模型的任何特殊“表示”。它将模型作为参数并封装表示逻辑

以你的例子来说，也许是这样的：

public static function getProductType($productKey)
{
    if (!array_key_exists($productKey, self::$productTypes)) {
        return null;
    }
    return self::$productTypes[$productKey];
}

public static function getProductTypes()
{
    return self::$productTypes;
}

class Model_Product
{
    public static function getAllTypes()
    {
        return array(/* key-value pairs */);
    }

    //returns non human readable value
    public function getType()
    {
        return $this->_type;
    }
}

class Model_Product_Presenter
{
    protected $_model;

    public function __construct(Model_Product $model)
    {
        $this->_model = $model; 
    }

    //returns human readable value
    public function getType()
    {
        $types = $this->_model->getAllTypes();

        if (!array_key_exists($this->_model->type, $types)) {
            return null;
        }
        return $types[$this->_model->type];
    }

    public function getDateCreated($format = "Y-m-d")
    {
        return date($format,$this->_model->timestamp);
    }
}

您可以更进一步，创建一个基本presenter类来定义任何常见任务，即将时间戳转换为日期、格式化数字等

更新： 对于匿名访问产品类型列表，我认为通过静态方法将其作为产品模型的责任没有任何危害。并非所有静态方法都是邪恶的。在我看来，出于这个目的使用静态方法是可以的，因为它声明了一个全局常量

在一个更复杂的场景中，我将把这个职责委托给一个单独的类，比如Model_ProductType。以下是生产中此类复杂模型的一个示例：

---

如果所有key=>value数据都必须用于某个下拉元素，那么情况会怎样？如果我只处理实体，选择很简单，但在构造之外，当我不使用任何实体，但我需要与理论实体相关的数据时，我仍然处于第一步。在我看来，维护产品类型列表和相关的人类可读描述应该是模型的责任。在您的示例中，根据复杂性，它可能是产品模型的一部分，也可能是ProductType模型。如果需要匿名访问维护的列表，那么就这样吧。我将使用Magento源代码中的产品模型示例更新我的答案。他们的产品/类型要求似乎相当复杂，显然需要一个自己的类。感谢您的回复，Christian。阅读你对这些问题的看法很有帮助。就Magento而言，我认为Magento是一个伟大的应用程序，但它的结构与我们自己的有点不同。他们倾向于使用单例模式和静态方法来驱动他们的应用程序，而我们没有。这并不是说我们找不到一些好主意。我会进一步研究你在这里提出的建议，看看是否合适。再次感谢！