Thanks Jeff, makes sense. I've since been digging around one of my goto/"how do they tackle it" open source rails projects and see similar approaches.
In this case, the Spree e-commerce platform. On 14 Dec, 17:00, Jeff <[email protected]> wrote: > On Dec 14, 10:24 am, Andrew Edwards <[email protected]> > wrote: > > > Hi, > > > Given the convention of fat models to handle business logic, is there > > a point where you might be justified in using a separate plain ruby > > object(s) to orchestrate certain business logic interactions, > > essentially a middle layer between your controllers and models for > > high level functions? > > If you look at the InventoryTransaction model below you will see the > > sort of methods I mean. In this case they are similar to factory > > methods I suppose. However, I could end up with around 30+ different > > method handling different kinds of inventory adjustments. > > The idea is fat model *layer*, not necessarily fat model classes. You > should feel free to factor out inventory-handling methods into > separate Ruby modules or classes, and use them from within your > InventoryTransaction class. That way your ActiveRecord class isn't > cluttered with lots of methods. I tend to keep such modules and pure- > Ruby classes in the models directory, but some people prefer to keep > them in lib/ instead. > > Jeff > > purpleworkshops.com -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
