Re: [rails-oceania] Rails is Not Your Application ...
The more I think about this article, the more I feel sick. Service? Manager? 10s of thousands of lines of code? This isn't Java. Next he'll be writing factory classes and going to conferences to talk about using singletons to improve testability. Cool architecture, bro. "My application was a ball of ActiveRecord objects." If you look at any Ruby library, or Java library for that matter, its API is comprised of a collection of classes and methods. A Rails application has just such an API too, comprised of whatever you put in app/models. If he has stuff in lib with names like XyzService and AbcManager, then I think he needs to move them into app/models and rename them to reflect the things they are responsible for coordinating. And run rdoc or similar on it and sit back and look at it and say, "There it is. My application's domain modelling." -- 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.
Re: [rails-oceania] Rails is Not Your Application ...
In a perfect world the business/sales guys are held back from complete insanity by reason directed by developers. In the real world this is seldom the case, especially in larger companies (which is why I've tried very hard to stick with start-ups). Abstraction and layers buy you some wiggle room when biz/sales wants a "small change" at zero hour. I've found Rails is almost more trouble than it's worth when dealing with companies that aren't more development driven. Rails (strict mvc) is a philosophy that, when not followed, wages jihad against you in some very annoying ways. Examples of this are multiple databases, multiple apps against one database with different permissions (engines sort of solve this), shared widgets (partials) initiated by multiple controllers, mixing db/no-sql, etc. Sure - this is all possible and we've all done it, but, it's not Rails' strong suit (although, now that I think of it, it's not really anything's strong suit, it just sucks). -ben On Sun, Oct 23, 2011 at 4:56 PM, Mark Ratjens wrote: > "Last year I was involved in my most complex Ruby on Rails application to > date that is now 23K lines of model code, 14K lines of controller code, and > 4.5K lines of lib code." > > That many lines of code piques my suspicion that there's some pattern > recognition/refactoring that need to happen. It's also likely that the > resultant abstractions have nothing to do text book architecture. > > Caveat: I haven't seen the code ... > > > On Sun, Oct 23, 2011 at 3:16 PM, Adam Boas wrote: > >> 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 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
Re: [rails-oceania] Rails is Not Your Application ...
"Last year I was involved in my most complex Ruby on Rails application to date that is now 23K lines of model code, 14K lines of controller code, and 4.5K lines of lib code." That many lines of code piques my suspicion that there's some pattern recognition/refactoring that need to happen. It's also likely that the resultant abstractions have nothing to do text book architecture. Caveat: I haven't seen the code ... On Sun, Oct 23, 2011 at 3:16 PM, Adam Boas wrote: > 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 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. > -- 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.
Re: [rails-oceania] Rails is Not Your Application ...
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 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.
Re: [rails-oceania] Rails is Not Your Application ...
I put non-ORM classes - or "services layer" classes - in app/models, not lib. To me, lib seems like the place to put library (i.e. generic, or not application specific) Ruby files that don't happen to be packaged as gems. To me, the directory 'app' implies 'application specific'. In the example linked, pay roll models seem very application specific so if it were me, I'd put them inside the app directory somewhere. Am I wrong? What is the best practice with regards to app/models versus lib? -- 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.
Re: [rails-oceania] Rails is Not Your Application ...
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 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.
[rails-oceania] Rails is Not Your Application ...
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.
