关于Magento模型和ORM基础

　　对于任何一个MVC架构，模型(Model)层的实现都是占据了很大一部分。对于Magento 二次开发来说，模型占据了一个更加重要的位置，因为它常常包含了一部分商业逻辑代码(可以说它对，也可以说它错)。这些代码在其他的MVC框架中往往出现在控制器或者帮助函数中。

　　传统的PHP MVC架构中的模型

　　本来MVC的定义就不是很清晰，不同的人有不同的看法，而对于模型的定义争议就更多了。在MVC模式被广泛采用之前，PHP程序员往往通过SQL语句直接操作数据库。也有些程序员通过一个SQL抽象层来操作数据库(比如AdoDB)。程序员往往关注SQL语句本身，而不是和数据相关的对象。

　　虽然直接操作SQL的方式一直被病诟，但是很多PHP框架还是以SQL为中心的。模型层提供了一系列对象，抽象/封装了数据操作，但是程序员最终还是需为模型层对象写SQL语句操作数据库。

　　还有一些框架回避了SQL，使用了对象关系映射(Object Relational Mapping，ORM)来解决这个问题。使用这个方法的话，程序员不用关注SQL，而只需要和对象打交道。我们可以操作一个对象的属性，当“Save”方法被调用的时候，对象的属性会作为数据自动的被写入数据库。有些ORM框架会根据数据表的信息自动推测对象的属性，也有框架要求用户显示的生命对象属性和表的关系。比较有名的ORM框架有ActiveRecord等等。【注：ActiveRecord源自Ruby on Rails，不过现在PHP也有了】

　　关于ORM的概念，我就解释到这里。但是和许多计算机领域的其他概念一样，ORM的定义也越来越模糊了。我不想在这片文章中讨论关于ORM的争议，所以我说的ORM就是那个最基本的ORM概念。

　　Magento的模型

　　Magento理所当然的也追随潮流应用了ORM。虽然Magento自带的Zend框架提供了SQL抽象层，但是在大多数情况下我们将通过Magento自带的模型和我们自己的模型来进行数据访问。他和视图层(View)一样，Magento的模型层也不是简单的ORM，而是一个高度灵活，高度抽象甚至有点令人费解。

　　解剖Magento的模型

　　大部分的Magento模型分为两类。第一类是基本的ActiveRecord类型，一张表一个对象的模型。第二类是Entity Attribute Value(EAV)模型。【注：EAV翻译成“实体属性值”有点词不达意，还是就叫EAV的好】Magento自己定义了一个数据类型叫做模型集合(Model Collection)。顾名思义，模型集合就是一个对象里面包含了很多模型对象。Magento的创造者Varien团队实现了PHP类库的标准接口，“IteratorAggregate”，“Countable”。这样模型集合就能调用这些方法，这也是模型集合和数组的区别。

　　Magento的模型并不直接访问数据库。每一个模型都有一个资源模型(Resource Model)，每一个资源模型拥有两个适配器(Adapter)，一个读，一个写。这样的话逻辑模型和数据库访问就分开了，所以从理论上讲更改底层数据库只需要重写适配器就可以了，所有上层代码都不需要更改。

转载于:https://my.oschina.net/u/3840660/blog/3033391