One thing that springs to mind here is that by extending Zend_Form you are substituting Zend_DB’s fluff with Zend_Forms in your ‘object’ class. So really the coupling moves from Zend_DB to Zend_Form.

Definitely an interesting substitution though, food for thought! :)

Has anyone found/come up with any other good solutions in the interim?

Aside from what seems to be questioning a gut feeling, you don’t really specify any particular issue with what you’re doing so maybe what you’re after is some additional justification…

First you could mention the added flavour that a row class would bring to this mix:

// in your table class
protected $_name = ‘persons’;
protected $_rowClass = ‘Persons_Row’;

class Content_Row extends Zend_Db_Table_Row_Abstract implements Some_Cool_Class
{
protected function _insert()
{
if(is_null($this->date_created)) {
$this->date_created = date(’Y-m-d H:i:s’);
}
}
}

Then that your persons class is now freer to subclass something like say an observer pattern class:

class Persons extends Something implements Something_Else …

Finally (since it’s too late for anything else to spring to mind rather than this being a grand reason) I’ll wave my hand and say I’ve been taking this approach. I’ve not however had the form tied so tightly though I do like the idea.

Fat Model, skinny controller in a flexible more easily testable package; looks good.

I think it’s hard to foreseen if a class will be reusable or not, I’m mean, will be “need” in another process or not, so I always try to loose the coupling the most I can.

So to me, having this new layer is very cheap and worths the price, always. It’s cleaner and gives back to Model it’s actual role, that is take care of the logic, the “information”, and let the TableGateway take care of the “data”.

1. How reusable is this package iam creating? Is abstracting it really worth the effort and if iam going to absctract how abstract would it need to be to be reusable?

2. Enviorment, in the context of your example its realy the duty of the controller to couple both models together. Hence all the methods described in the linked article Dependency Injection can be applied. But wich solution all depends on rule 1.

I had a quick look at Zend_Di, which looks like a nice simple solution to the Dependency Injection.

I wouldn’t hold your breath for more comments, this blogs not popular enough ;)

It seems there are a whole bunch of alternative implementations available to you, though. Persons could extend an abstract class with default definitions of getTable and getForm, instead of being static methods of Persons. That abstract class could use the same kind of path magic that Zend_Loader uses, or you could just stick to your filename convention; using the __CLASS__ magic constant for the directory name.

That’s just off the top of my head… I don’t know if this fits smoothly in to your TDD routine. My head always hurts after reading Fowler (always worth it, though).

Can’t wait to see more comments on this. Good post.