Zend Framework: Proper way to interact with database?

Question

I'm fairly new to the Zend Framework and MVC and I'm a bit confused by Zend_DB and the proper way to interact with the database.

I'm using the PDO MySQL adapter and have created some classes to extend the abstract classes:

class Users extends Zend_Db_Table_Abstract {
    protected $_name = 'users';
    protected $_primary = 'user_id';
    protected $_rowClass = 'User';

    public function getUserbyID($id) { /* code */ }
    // More code here
}
class User extends Zend_Db_Table_Row_Abstract {
    // Code here
}
class Widgets extends Zend_Db_Table_Abstract {
    protected $_name = 'widgets';
    protected $_rowClass = 'Widget';

    public function getWidgetsfromUser($userid) { /* code */ }
    // More code here
}
class User extends Zend_Db_Table_Row_Abstract {
    public function doSomethingWithWidget() { /* code */ }
    // More code here
}

There seems to be so many ways to access the DB (fetchAll(), find(), fetchAll() through adapter, insert(), createRow() and save(), select() object) that I always find myself going back to the docs to figure out what I should be doing.

SO has taught me prepared statements are the way to go, and I've been trying to use rowsets and row (should I be?), but I'm still confused as to what's the best way to interact with the database?

(apologies for the terribly open ended question)

Answer 1

In general, people prefer to access the database through the Table and Row objects, to match their habits of object-oriented programming.

The OO approach is useful if you need to write code to transform or validate query inputs or outputs. You can also write custom methods in a Table or Row class to encapsulate frequently-needed queries.

But the object-oriented interface is simplified, unable to perform all the types of database operations you might need to do. So you can delve deeper and run a SQL query against the Zend_Db_Adapter methods like query() and fetchAll() when you require finer control over your SQL.

This is pretty common for object-oriented interfaces to databases. An OO layer that could duplicate every SQL feature would be insanely complex. So to compromise, an OO layer usually tries to provide easy ways to do the most common tasks, while giving you the ability to go under the covers when necessary.

That's a very general answer to your very general question.