[rspec-users] Dreading Controller Specs
pergesu at gmail.com
Wed Oct 22 16:32:29 EDT 2008
Matt Wynne <matt at mattwynne.net> writes:
> 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.
I think any app with a rich domain model benefits from a service layer
that uses that model. When building Rails apps, stuff is relatively
simple and the controllers *are* the service layer. That's how I think
of it, anyway. Most of the time that's sufficient, but sometimes it
gets complex enough that you want to split out some of the logic.
Whenever I've had to do that, I've created some kind of Service object
to handle the coordination of domain objects, and I let the controller
handle all the HTTP shit and pass required info into the Service. Now,
I haven't had to do that often - I think I've written like 5 or 6 of
these Service objects in the last 3 years of daily Rails work - but when
I have, I've been happy with the testability and maintenance benefits.
Separation of concerns ftw!
More information about the rspec-users