[rspec-users] Dreading Controller Specs
matt at mattwynne.net
Wed Oct 22 03:45:52 EDT 2008
On 21 Oct 2008, at 22:13, Stephen Eley wrote:
> On Tue, Oct 21, 2008 at 3:57 PM, Rahoul Baruah <baz at madeofstone.net>
>> * the presenter/service's role is to coordinate the models - so its
>> are purely about mocking the associations and the calls inbetween
>> * 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
> 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.
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?
More information about the rspec-users