On 21 Oct 2008, at 22:13, Stephen Eley wrote:
On Tue, Oct 21, 2008 at 3:57 PM, Rahoul Baruah <[EMAIL PROTECTED]>
wrote:
* the presenter/service's role is to coordinate the models - so its
specs
are purely about mocking the associations and the calls inbetween
them
* the presenter/service isn't a model (not ActiveRecord::Base) - so
it's not
adding extra responsibilities to the models
* it is pretty much a service layer sat between controllers and
models
There seems to be some overload on the word "Presenter" in Railsspeak.
As best I can tell, people are using it to refer to two or more
totally different patterns. Initially I thought presenters were for
encapsulating limited-domain *controller and view logic* in such a way
that they could be embedded in other controllers, thus allowing
composition in views. Things like sidebar widgets, or components of a
dashboard, or a reusable address box, etc. Stuff that benefits from
maintaining its own data so you can't just a partial, but it's still
more about the view than the model.
Right on - that was going to be my response too. Martin Fowler
actually retired the 'Model View Presenter' pattern precisely because
of this confusion.[1]
If we say that a Controller should be responsible for handling HTTP
requests, and co-ordinating the appropriate (persistence /
presentation / etc) work, that seems like enough responsibility.
If we assume that the work to be done against the database or other
sub-systems is non-trivial, then we should not directly call the
persistence layer (= Models in Railsspeak) from the Controller, but
delegate that to another class. It seems like Service is a much more
appropriate name than Presenter here, since this work nothing to do
with presentation. I buy the thing about conductors, and I like the
new-bamboo guys, but I do wonder whether there's some wheel
reinvention going on there.
If we also assume that the data to be presented is non-trivial,
composed of data from multiple database tables, then we need some
object to model the data in this presentation domain. I think this is
where Presenter comes in, although I'm still not sure this is really
an appropriate name. This class can be facade over the various
persistence-layer objects needed for the specific presentation task.
On another project, in another language, in a galaxy far, far, away,
we sprouted a whole layer of POCO presenation 'models' like this, and
it felt like such a relief once we'd broken out this extra layer.
Does this make sense to anyone else?
cheers,
Matt
[1]http://martinfowler.com/eaaDev/ModelViewPresenter.html
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
