Question

I am not suggesting that all models are tables.

What I am asking is whether every single table must also have its own class defined specifically for it when using Zend? Is there any way of getting away from this awkward boiler-plate coding. We’re just starting to look into Zend (hoping to leave procedural PHP land!) and my colleague thinks this could end up being pretty time-consuming.

Is this the reason for people using ORM solutions? Is there any other way around this?

Thanks for your replies.

Answer 1

The Zend Table classes follow the Table Data Gateway pattern, which by definition

… holds all the SQL for accessing a single table or view: selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database.

In the book, Fowler is not that rigid about that, saying that

for very simple cases, you can have a single TDG that handles all methods for all tables. You can even have one for views or even for interesting queries that aren’t kept in the database as views.

However, except for being able to use Views, Zend_Db_Table does not accomodate for this. You can create queries to multiple tables, but those would have to be made through the Zend_Db_Adapter directly or – when using joins – by switching off the integrity check. Otherwise, you have to use the API offered by Zend_Db_Table Relationships

So yes, one instance should correspond to one table or view. You do not need to create classes for that though if you dont plan on extending the classes. Zend_Db_Table_Definitions allow you to configure Zend_Db_Table instances on the fly.

Note that TDG is a DataSource Architectural Pattern and not an Object-Relational pattern. It’s purpose is not to help with impedance-mismatch, but with separating database access code from business logic.