P.S. Couple methods you listed seem good candidates to remain in model class. I suspect they are core of business logic and most important actions called in the controller.
If there's more than a dozen of them, I'd probably try to make them very short by extracting common parts into utility methods (and move them to another module). On Dec 15, 8:44 pm, Wojciech Kruszewski <[email protected]> wrote: > I try to keep only high-level functionality and business logic in the > models. > > Here's the drill: > > 1. identify things that are not specific to your model or application > and then extract them into a plugin > > 2. identify things that are specific to your application, but not to > your model and extract them into a lib > > 3. find groups of related methods that are lower level (used only in > this model itself) and extract them into modules (in models dir) > > What's left is a concise interface with some behaviours in declarative > style (like acts_as_taxable). > > I've seen this working pretty well in largish 7 years old Rails > application. Initially I haven't appreciate such terse models until I > came across some bloated ones. I then couldn't quickly figure out what > I can do with an instance of this model. > > Regards, > Wojciech > > --http://twitter.com/WojciechK > > On Dec 14, 6:00 pm, 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.
