1

首先是一些背景。我们最近从基于 Zend_Db_Table 的解决方案转换为基于实体的解决方案（Doctrine）。随着我们的应用程序的增长，表类变得越来越难看。一些表使用 ENUM 列来存储基于字符串的键，这些键通过静态方法转换为人类可读的字符串。像这样的东西：

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;
}

在转向基于实体的系统时，我尽量避免使用静态方法。我将价值翻译的关键转移到一个视图助手中，并称之为一天。最后，我发现这还不够，因为我们需要以 JSON 对象的形式返回它们，这发生在表示层之外（即不能直接访问视图助手）。

有没有人对这些方法的适当位置有任何理论？我应该创建单独的对象来进行从键到人类可读值的转换，在实体对象上实现静态方法，还是其他什么？

4

1 回答 1

0

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

所以使用你的例子，也许是这样的：

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);
    }
}

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

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

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

https://github.com/magento/magento2/blob/master/app/code/core/Mage/Catalog/Model/Product/Type.php

于 2012-07-02T18:50:24.640 回答