重点#1：Magento核心团队不愿意从源树中删除或重命名方法.创业文化意味着他们避开了测试,加上一个公共项目,这意味着他们无法控制人们对他们的产品做了什么.他们不会删除方法并冒险破坏事物,而是留下调用新方法的方法.这样,即使那里有调用该方法的旧代码,它们也会被覆盖.

重点#2：集合继承链很棘手,并且在代码库的某些部分中应用不一致.这是正在清理,但它仍然可以轻松地让你循环.

重要的一点#3：我在猜测如何使用和发生这么多.我不是这里的最终权威,我只是想要弄清楚它的人.以下具体内容参见1.6,但这些概念适用于所有版本

所有集合都继承自VARien_Data_Collection_db类.这是模拟“收集从数据库加载的一系列对象”的基本概念的类.这个类有一个方法addFieldToFilter.

public function addFieldToFilter($field,$condITion=null)
{
    $field = $this->_getMapPEdField($field);
    $this->_select->where($this->_getConditionsql($field,$condition),null,Varien_Db_Select::TYPE_CONDITION);
    return $this;
}

这是一个简单的实现,它为理论查询添加了where子句.

接下来,有两个抽象类将Varien_Data_Collection_Db作为祖先. Mage_Core_Model_Resource_Db_Collection_Abstract和Mage_Eav_Model_Entity_Collection_Abstract.

Mage_Core_Model_Resource_Db_Collection_Abstract是“常规非EAV模型”的集合类.它既没有addFieldToFilter方法,也没有addAttributeToFilter方法.它依赖于基础Varien_Data_Collection_Db类的实现.

Mage_Eav_Model_Entity_Collection_Abstract是EAV模型的集合类.它有一个addAttributeToFilter方法,它更复杂.

public function addAttributeToFilter($attribute,$condition = null,$joinType = 'inner')
{
    if ($attribute === null) {
        $this->getSelect();
        return $this;
    }

    if (is_numeric($attribute)) {
        $attribute = $this->getEntity()->getAttribute($attribute)->getAttributeCode();
    } else if ($attribute instanceof Mage_Eav_Model_Entity_Attribute_Interface) {
        $attribute = $attribute->getAttributeCode();
    }

    if (is_array($attribute)) {
        $sqlArr = array();
        foreach ($attribute as $condition) {
            $sqlArr[] = $this->_getAttributeConditionsql($condition['attribute'],$condition,$joinType);
        }
        $conditionsql = '('.implode(') OR (',$sqlArr).')';
    } else if (is_string($attribute)) {
        if ($condition === null) {
            $condition = '';
        }
        $conditionsql = $this->_getAttributeConditionsql($attribute,$joinType);
    }

    if (!empty($conditionsql)) {
        $this->getSelect()->where($conditionsql,Varien_Db_Select::TYPE_CONDITION);
    } else {
        Mage::throwException('Invalid attribute identifier for filter ('.get_class($attribute).')');
    }

    return $this;
}

那是因为属性查询不是直接的“where”查询.此外,此方法旨在获取属性名称,属性数据库ID或实例化属性对象.您没有向过滤器添加字段,而是向过滤器添加属性.因此,根据EAV的实现以及存储属性的表,您需要添加不同的sql代码(在主表上直接查询,在其中添加一个连接表,等等)

这会产生问题.由于此EAV集合对象继承自基本集合对象,因此addFieldToFilter仍然存在,并且仍会为EAV查询添加基本where条件,这可能会使最终用户因为没有按照他们的想法而混淆.因此,EAV集合类也有这个

public function addFieldToFilter($attribute,$condition = null)
{
    return $this->addAttributeToFilter($attribute,$condition);
}

它将对addFieldToFilter的任何调用包装到addAttributeToFilter(同样,在EAV模型上).因此,如果您有EAV模型,则可以使用addFieldToFilter或addAttributeToFilter.如果您正在使用常规模型,则可能只调用addFieldToFilter,addAttributeToFilter不存在.

理想情况下,方法名称从一开始就是统一的,但一旦分裂发生,Magento团队选择继续支持拆分,转而支持向后兼容.

等等,还有更多

代码库中有两个直接从Varien_Data_Collection_Db继承的集合.这些是Mage_Sales_Model_Resource_Sale_Collection和Mage_review_Model_Resource_Review_Summary_Collection.在1.6之前的Magento CE版本中,此数字更高.虽然这不会影响过滤问题,但它确实会混淆继承链,因此您应该注意它.

许多非EAV集合将实现他们自己的addFieldToFilter来对变量进行健全性检查,或者如果他们做了一些非标准的事情,则稍微跳过查询参数.

通过重新定义addAttributeToFilter,EAV集合也可以参与此行为.同样,这样做是为了添加不适合基本Magento集合加载的自定义逻辑.