A fairy dies every time a developer speaks the phrase 'Services Layer'. Sometimes it feels like Object Oriented programmers just can't commit to OO design. They constantly want to pull application logic up into services so they can make it more procedural. If no-one has ever killed a fairy in their presence then they stuff it all into the controller, but if someone has spoken that fairy killing phrase in their presence then they righteously go about writing services in roughly the same way they would have written fat controllers and call it good design.
It is hard to argue this stuff without concrete examples but in general I don't see why logic not belonging to a persistent model makes it a candidate for a service. I probably have stronger feelings than most about this having done so many years of J2EE and having virtually never experienced the imaginary reuse my services were supposed to have given me. I never even found them to be a valuable abstraction as they constantly promote a procedural approach. Developers just don't seem to believe that the normal rules of cohesion should apply when working on a service. I do think that if every class in your domain is an ActiveRecord class then you probably either have a reasonably trivial problem or a poorly designed domain. By trivial, I don't mean insignificant or not hard but just one that perfecly fits the CRUD paradigm that Rails so elegantly supports. Cheers, Adam On 23/10/2011, at 2:33 PM, Chris Berkhout wrote: > My reading of this article: > > Your application may be more than just DB-backed models and REST-based > HTTP controllers. > Don't be afraid to introduce additional objects to better model your domain. > > A services layer sits between your external interfaces (e.g. > controllers, and others) and your models. It can reduce duplication of > logic among interaces, and support complex interactions involving > transactions across multiple models and the coordination of multiple > responses. > > A services layer doesn't belong in /app/models or /app/controllers. > You can put in under /lib or even extract it to an external gem (which > you configure to access specific models in your application). > > > My response: > > If your application's only interface is REST controllers and the > operations your application provides are simple enough to be > encapsulated in individual models, then Rails is your application. > Otherwise, do introduce additional structures. > > > I'm interested to hear other's thoughts. > > Cheers, > Chris > > > On Sun, Oct 23, 2011 at 5:33 AM, jamesl <ladd.ja...@gmail.com> wrote: >> I found this article insightful and thought others might as well. >> http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-oceania@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-oceania@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
