[rspec-users] Dreading Controller Specs

[Matt Wynne]

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>  
> 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