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 ha

Answer 1

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 2

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 :)