2009-06-30 40 views
9

Zend Framework Quickstart中,從擴展Zend_Db_Table_Abstract的模型到表格數據網關模式有所變化。Zend Framework ORM樣式的表數據網關與擴展Zend_Db_Table_Abstract

就我個人而言,我對這種模式沒有太多的經驗,我一直聽到這個應該最有可能被用來代替舊的方式。

從快速入門的簡單例子:

老辦法:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract 
{ 
    protected $_name = 'tablename'; 

    // do stuff 
} 

新方法:

// The actual model 
class Default_Model_Guestbook 
{ 
    protected $_comment; 
    protected $_created; 
    protected $_poster; 
    // list continues with all columns 
} 

// Dbtable for this model 
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract 
{ 
    /** Table name */ 
    protected $_name = 'guestbook'; 
} 

// Mapper 
class Default_Model_GuestbookMapper 
{ 
    public function save($model); 
    public function find($id, $model); 
    public function fetchAll(); 
} 

從我用這種編程風格缺乏經驗,我發現很難掌握實際情況l受益於後一種方式;我知道這種方法儘可能地將數據庫從實際的邏輯中分離出來,這在理論上應該更容易地轉換到另一個數據庫平臺。但是,我真的沒有看到這發生在我工作的任何項目上。

幾乎毫無疑問,我忽略了一些東西,所以我很樂意聽取您的建議。

問題:

  • 可能有人請向我解釋爲什麼(或者),後者是更好的做法?

  • 我應該從舊的方式切換到新的方式或仍然會有適當的理由與代表數據庫錶款堅持?

在此先感謝。

+0

不是一個真正的答案,所以這是她的。幾年後,我發現抽象是一種藝術形式,藝術並不總是有原因的。今天,我抽象出我需要的最低限度,並且做一些事情,這樣我就不得不盡可能少地編寫代碼,在你的情況下,如果增加這個額外的抽象層次,將不會發生。 – 2009-06-30 13:34:28

+0

爲了澄清,Zend_Db_Table *是* TDG/RDG模式的實現。發生的是他們正在轉向Data Mapper模式。 – jason 2009-06-30 15:31:49

回答

6

這裏是我在爲什麼這是一個更好的做法的解釋之一:

我覺得真正利益,這是無縫地改變你的數據源的能力。通過在您的應用程序中添加一個額外的抽象層,您的模型不再代表數據庫表(我認爲它絕不應該有),因爲模型應該是數據的表示(而不是通往它的網關)。數據庫訪問層應該由模型封裝,讓您有更大的靈活性。例如,假設您的應用程序需要開始使用SOAP服務或XML-RPC,因爲它的數據源/存儲空間不足。通過使用數據映射器方法,您具有明顯的優勢,因爲您已經具備必要的結構來添加這些特定的數據層接口,而不會對現有模型產生太多(如果有的話)干擾。

你應該這樣做嗎?這是一個實用的問題。就我個人而言,我喜歡讓自己放心,我正在開發一些靈活並遵循(商定的)最佳實踐的東西。但是,只有您知道創建更靈活的應用程序是否會使您的項目更容易,無論是現在還是未來的某個時間,都可以構建和維護。

對我來說,我只是覺得自己在創造一些東西,我認爲這是最佳實踐,而且通常會帶來紅利。

0

這很有用,因爲你可以這樣做$insert = new Model_Guestbook($param1, $param2, $param3); - 意味着當有人來到項目中時,他可以在不知道數據庫結構(通過檢查源/按模型接口)的情況下輕鬆創建新實例。這僅僅是這種方法提供的好處:)

+0

我並不認爲這是一個很大的好處,因爲這意味着模式更改會導致需要在多個地方更改相應的代碼。我仍然覺得我徹底忽略了一些東西。 – 2009-07-01 07:43:40