It sounds like you're trying to build your own inversion of control implementation in your application domain. The Zend notion of a Model is usually coupled to Zend_Db_Table which is really an object representation of your database tables. My contention comes from the terminology in the Zend context, where a the Model_* namespace is used (by Zend convention) for Db_Table_* objects and so developing a DI implementation in all your models would be a mix of concerns.
If you do take this route, I'd be interested in how you design your various models.
my 2 cents...
On Wed, Jun 3, 2009 at 5:49 PM, Ed Lazor <edlazor@internetarchitects.biz> wrote:
Hi Jon =)
It seems like you're recommending an approach I've been using:
echo $this->displayPerson($Person);
As compared to the new approach of:
$Person->setDisplay('HTML');
echo $Person->display();
In this new approach, the model's display method passes the model's
data to an internal component (another object) that is responsible for
converting the data into a new output format - which the display
method returns.
In psueo-code terms, setDisplay ends up looking something like this:
public function setDisplay($format) {
$this->_display = OutputFactory::getInstance($format);
}
and the display method ends up looking like this:
public function display() {
return $this->_display($this->toArray());
}
That way the responsibilities are maintained separately and you the
OutputFactory can be used anywhere?
What do you think?
-Ed
On Wed, Jun 3, 2009 at 1:51 PM, Jon Lebensold<jon@lebensold.ca> wrote:
> Hey Ed,
>
> usually a Model's responsibility does not include how it's viewed (think of
> a PersonModel that appears in an XML dump, a JSON web service and on an HTML
> page). I would suggest writing a view helper that would accept a certain
> kind of model that implements a collection of properties / methods in an
> interface so that my view code could be handled by an object that would only
> have that concern.
>
> Best,
> -
> Jon
没有评论:
发表评论