Nothing is keeping you from creating a DomainModel that either uses a
service layer OR directly ties to DbTable (via composition) to persist
your data.
A skeleton I like to use for this type of integration is something
similar to this:
class Person
{
protected $_row = null;
static public findById($id)
{
$table = new SomeTableThatExtendsZendDbTable();
$row = $table->find($id);
if ($row) {
return new self($row->current());
} else {
throw new NotFoundException();
}
}
public function __construct($options)
{
if ($options instanceof Zend_Db_Table_Row) {
$this->_row = $options;
} else {
$table = new SomeTableThatExtendsZendDbTable();
$this->_row = $table->createRow();
}
}
...
}
Naturally, your model becomes more dependent on your coding (vs.
database introspection), but ultimately you have more control. And, as
you can see above, its consuming Zend_Db_Table as its persistence layer.
On the other hand, you can use Outlet, or Doctrine.. both are solid set
of tools for ORM- if that is what you are looking for.
-ralph
KimG wrote:
Zend_db is OO allright. Let me rephrase it: i don't like the model where you
have to extend some base classes in order to get persistency.
i prefer to use the VO / DAO pattern where you persist the VO by means of
some 'external' framework. my background is Java and i've use hibernate a
lot to persist objects and it uses that model.
kim
Matthew Weier O'Phinney-3 wrote:
-- KimG <[email protected]> wrote
(on Tuesday, 23 June 2009, 06:57 AM -0700):
Yes, i'm aware of the zend_auth stuff, but i dislike the zend_db* - and
hence the zend_auth - methods since they work in a non-object oriented
way.
Um... Zend_Auth and Zend_Db are *completely* OOP -- all of ZF is. Could
you please qualify your statement? I'm curious what in particular you
see as non-OO.
--
Matthew Weier O'Phinney
Project Lead | [email protected]
Zend Framework | http://framework.zend.com/
