In the Zend Framework Quickstart, there has been a change from models that extend Zend_Db_Table_Abstract to the Table Data Gateway pattern.

Personally, I have not had much experience with this pattern and I keep hearing this should most likely be used instead of the old way.

A short example from the quickstart:

Old way:

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

    // do stuff

New way:

// 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();

From my lacking experience with this style of programming, I find it hard to grasp the actual benefits from this latter way; I understand that this method seperates the database from the actual logic as much as possible, which should in theory make a transition to another database platform easier. However, I really don't see this happening on any project I am working.

There is almost no doubt that I am overlooking something, so I'd love to hear your advice.

The question:

  • Could someone please explain to me why (or if) the latter is better practice?

  • Should I switch from the old way to the new way or are there still proper reasons for sticking with models that represent database tables?

Thanks in advance.


Not really an answer, so it is her. After several years I found out that abstraction is a form of art, art not always have reasons. Today I abstract the minimum I need and do stuff so I will have to code as less as possible, which in your case, if add this extra level of abstraction, won't happen.

Written by Itay Moav

Just to clarify, Zend_Db_Table is an implementation of the TDG/RDG pattern. What's going on is that they're moving to a Data Mapper patter.

Written by jason

Accepted Answer

Here's my explanation at why this is a better practice:

I think the real benefit to this is the ability to seamlessly change your data sources. By adding an additional layer of abstraction into your application, your models no longer represent a database table (it never should have, in my opinion) as a model should be a representation of the data (not a gateway to it). The database access layer should be encapsulated by the model, allowing you more flexibility.

Say, for instance, your application needed to start using a SOAP service or XML-RPC as it's data source/storage. By using the data mapper approach, you are at a distinct advantage, as you already have the necessary structure in place to add these specific data layer interfaces without much (if any) interference with your existing models.

Should you do it, though? That's a pragmatic question. Personally, I like to have the peace of mind that I'm developing something that is flexible and follows (agreed on) best practices. However, only you know whether creating a more flexible application will make your projects easier, either now or some time in the future, to build and maintain.

For me, I just like the feeling that I'm building something, I consider to be best-practice and it often pays dividends.

Written by Kieran Hall
This page was build to provide you fast access to the question and the direct accepted answer.
The content is written by members of the community.
It is licensed under cc-wiki