(on Wednesday, 03 June 2009, 06:04 PM -0400):
> 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.
Um... no, actually, that's *not* our recommendation. The *_Model_*
namespace is for models you as a developer create. In the recommended
directory structure -- which is reflected in Zend_Application_Module_Autoloader
-- there is a separate component namespace *_Model_DbTable_* for your
Zend_Db_Table classes, which would be used as a data access layer for
your models. You can see this in action in the current iteration of the
QuickStart, where we use a DataMapper to map the models to the data
access layer (which uses Zend_Db_Table).
That said, I agree with you -- your models themselves shouldn't be
renderable, though I will sometimes recommend that your service layer
objects (which consume your domain models) have that capability.
> 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
>
>
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论