Model, Orm, Dao 和 Active Record 的异同点

Model, Orm, Dao 和 Active Record 的异同点，求高手解释，可以基于现在 PHP 的流行框架。能举例更好啦！

回复内容：

Model, Orm, Dao 和 Active Record 的异同点，求高手解释，可以基于现在 PHP 的流行框架。能举例更好啦！

很不巧，这几个词描述不是同一个层次的东西，没什么可比性，更谈不上异同。
在下口拙简述不能，干脆帮你找了点资料，你勉为其难多看下。

• Model
  恐怕你是在 MVC 里看到这个词的，如字面意思——模型，没什么特别的含义。
  具体可参考：http://zh.wikipedia.org/wiki/MVC

• ORM （Object Relational Mapping）
  关系型数据库里的数据转化为对象与对象的引用，这样就可以用面向对象的方式访问数据库了，省点脑力，增加开发效率。
  具体可参考：http://zh.wikipedia.org/wiki/%E5%AF%B9%E8%B1%A1%E5%85%B3%E7%B3%BB%E6%9...

• DAO （Data Access Object）
  就是在数据源（各种数据库）之上再铺一层代码，抽象出统一的接口，酱紫上层代码就不必为不同的数据源做不同的编码了。
  具体可参考：http://en.wikipedia.org/wiki/Data_access_object
  没图说个JB，上图：
  
  出自 Java 的技术文档 http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

• Active Record
  一种 ORM 的实现方式（多谢@杨益 ）。恕在下说不出其中奥妙，毕竟，是个阿猫阿狗都会习惯把数据库里一行记录当作一个可读写的实体，也许“一看就合我意”正是其奥妙本身吧。
  马丁老爷的书里倒是阐述过，下方 wiki 页面里也有他博客地址。
  具体可参考：http://zh.wikipedia.org/wiki/Active_Record

举个例子汇总一下这些名词的使用：
小强要开发一个应用，选择用MVC，先blabla……然后开始考虑Model层，再blabla……具体到业务对象（business object）怎么持久，首选当然是关系型数据库，但直接写sql太费事，那就用ORM，考虑怎么个映射法，就按Active Record那样做吧，一表一个类，一行一对象。然后blabla……测试、修正、发布。一段时间后，需求变更，改！需要新增一个数据源（比如Memcached），卧槽，业务对象和数据源耦合住了，改个球，先重构，写几个DAO塞进去，业务对象的数据从DAO里获取，而DAO来决定数据源。

---

……

refer:
http://*.com/questions/6640784/difference-between-active-r...
and
http://*.com/questions/3198419/orm-dao-datamapper-activere...

在做web开发中，经常会碰到这样几个概念：

Model
DAO，data access object，数据访问对象
ORM，object-relational mapping，对象关系映射
Active Record
这些概念都是和数据相关的，然而他们之间有怎样的区别呢？

首先来看Model，模型。模型是MVC中的概念，指的是数据和改变数据的操作（业务逻辑）。模型通常指代现实生活中的某样实体。以订单为例，每个订单都包含许多数据，如客户、价格、明细等等，这些数据都叫做订单这个模型的属性，此外，和订单相关的一些列操作，比如当购买时，你可能需要先检查库存，给与一定的优惠，再更新账户余额和积分等等，这些就叫做业务逻辑，也是模型的一部分，从代码上来讲，是要放在模型中的。

当模型执行完业务逻辑后，我们便要把模型中的数据保存到数据库中。如果我们直接把和数据库相关的代码放在模型里，会使得以后的维护相当的麻烦。在我之前的一个项目中，我们用户的增长相当快，导致一台数据库无法支撑所有的访问，不得不使用分库来解决问题。然而前人把SQL语句直接写在了模型这一层里，这导致分库相当的麻烦，我们只能先把这些SQL语句抽出来，才能把分库进行下去。我们把这些抽出来的SQL代码放到单独的一层，这一层便是DAL，Data Access Layer，数据访问层，它由许多DAO组成，目的便是把和数据库相关的代码封装起来，这样当我们执行分库时，便只用调整DAO的代码了，模型根本不用关心它使用的数据是放在A库还是B库。

DAO其实是来源于J2EE的一个设计模式，当初的目的也是使得企业更换数据库时，不用影响模型层的代码。

与DAO类似，ORM也是一种封装数据访问的概念。然而ORM不像DAO只是一种软件设计的指导原则，强调的是系统应该层次分明。ORM更像是一种工具，有着成熟的产品，比如JAVA界非常有名的Hibernate，以及很多PHP框架里自带的ORM库。他们的好处在于能将你程序中的数据对象自动地转化为关系型数据库中对应的表和列，数据对象间的引用也可以通过这个工具转化为表之间的join，而Hibernate甚至提供一套他们自己的数据查询语言HQL来解决复杂的查询问题。

使用ORM的好处就是使得你的开发几乎不用接触到SQL语句。创建一张表，声明一个对应的类，然后你就只用和这个类的实例进行交互了，至于这个对象里的数据该怎么存储又该怎么获取，通通不用关心。

Active Record则是随着ruby on rails的流行而火起来的一种ORM模式，它是把负责持久化的代码也集成到数据对象中，即这个数据对象知道怎样把自己存到数据库里。这与以往的ORM有不同，传统的ORM会把数据对象和负责持久化的代码分开，数据对象只是一个单纯包含数据的结构体，在模型层和ORM层中传递。而在Active Record中，模型层集成了ORM的功能，他们既代表实体，包含业务逻辑，又是数据对象，并负责把自己存储到数据库中，当然，存储的这一部分代码是早已在模型的父类中实现好了的，属于框架的一部分，模型只需简单的调用父类的方法来完成持久化而已。
来源：http://blog.pengqi.me/2011/03/30/difference-between-model-dao-orm-and-...

每次看到这个话题都想说一个我的观点，在web开发中有一个常见的误区就是把model和orm等同起来

这个误区的原因是大量的web开发实际上就是对数据库的CRUD操作，业务逻辑几乎就等同于orm操作

实际上，model就是包含了业务逻辑的类，跟orm没有必然联系，只要你把一段业务逻辑封装到一个单独的类，这个类其实就是model

所以我读代码的时候，一旦看到这种代码

phpclass Foobar extends Model {
}

只说明一件事情，这个人或者框架作者并没有真正搞清楚model和orm的关系，因为业务逻辑是多变的，所以根本不应该存在什么model基类

推荐一个短小精悍的ActiveRecord库，lloydzhou/activerecord · GitHub， 可以实现类似Yii的relation的效果。文档地址：http://lloydzhou.github.io/activerecord/

class User extends ActiveRecord{
  public $table = 'user';
  public $primaryKey = 'id';
  public $relations = array(
    'contacts' => array(self::HAS_MANY, 'Contact', 'user_id')
  );
}
class Contact extends ActiveRecord{
}
$user = new User();
// find one user
var_dump($user->notnull('id')->orderby('id desc')->find());
echo "\nContact of User # {$user->id}\n";
// get contacts by using relation:
//   'contacts' => array(self::HAS_MANY, 'Contact', 'user_id'),
var_dump($user->contacts);