Matt Wynne <[EMAIL PROTECTED]> 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! Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
