Zend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract

Question

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.

Answer 1

It's useful because you can do $insert = new Model_Guestbook($param1, $param2, $param3); - means when someone comes to the project, he can create a new instance easily without knowledge of the database structure (by checking the source / by model interface). This is just one of the benefits this method offers :)

Answer 2

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.

Answer 3

I'm in a similar boat and I'm sure I'm missing something.

Perhaps based on the responses the question needs to be revised.

I am implementing my project using the data mapper similar to the ZF 1.8 Quick Start app you mention, guestbook.

What I am concerned about is that with 50 plus tables, how does one adapt the guestbook app example to prevent unnecessary code and numerous files. If each table is implemented as it in in the guestbook, with 3 files per table that's quite a bit.

My second question is, with that implementation one would have to explicitly define the field names for each table in model (eg. class Default_Model_Guestbook). Is there a way around this, and even so, isn't part of the benefit, not having to do that?