What is the advantage of using a DataMapper with Zend_Db_Table as opposed to only using a DataMapper w/ the database adapter directly?

I was going through the Zend Framework quickstart tutorial, and in their demo code they use a data mapper which uses Zend_DB_Table to access the database (see: http://framework.zend.com/manual/en/learning.quickstart.create-model.html). It seems that Zend_DB_Table doesn't use prepared statements or provide a way to use transactions though. Therefore, I'm leaning towards just using a datamapper directly with a zend_db_adapter. With that in mind, can someone advise as to the situations where Zend_DB_Table would be advantageous? A开发者_JAVA百科ppreciate your input! Cheers.

In general, I see Zend_Db_Table as a quick and easy way to do single-table queries.

You can surely do joins with Zend_Db_Table, but since the class is targeted towards a specific table (after all, it is intended as a Table Data Gateway implementation), all such joins always feel - to me, at least - like an unnatural graft. In that case, I always tend towards straight adapter-based queries with joins, that could include your transaction handling.

Of course, in either case, it is certainly desirable to put all of this behind a model or mapper or service layer. Then, as you change these implementation details- say, start out with a Zend_Db_Table implementation, but later realize you need to join data from a another table, so you move to adapter-based queries - none of this will affect consumers of the model/mapper/service.

Hope this helps.

The way I see it, you want your code to be as Object Orientated as possible for maintainability and testability.

I guess it depends what other solution you would implement instead, but if the alternative is raw, bespoke SQL queries scattered arbitrarily around your code base and being passed around as arrays with whatever key values seemed appropriate in a particular instance, mappers and table gateways are much more structured. Your code will be more reusable.

Also, If you have an object representing a table row, you can dummy that object for unit testing.

It depends what your asking I guess, I'm being pretty high level and listing the advantages (as I understand them) against not using a model pattern at all...

Anyway, hope it helps :)

1. For example if you want to modify data from db
   
2. Or if you need to send mails to peoples on insert records and so on..