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://stackoverflow.com/questions/6640784/difference-between-active-r...
and
http://stackoverflow.com/questions/3198419/orm-dao-datamapper-activere...

在做web開發中，經常會碰到這樣幾個概念：

Model
DAO，data access object，Data Access Objects
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 uservar_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);

