Agreed with Jeff. The AR models really act as a wrapper class to DB tables. This helps to add an abstraction layer to SQL and marshall SQL selects into powerful ruby objects (the best part, in my opinion). With that in mind create non-AR models as needed, and only use the AR models when the actions really relate to that table/model.
A quick example. Let say you need to encrypt and decrypt fields in a single AR model. You could write your code within this model, since it is the only model that currently needs encryption. But, this will clutter the AR model with methods that don't directly pertain to it, and it won't scale work well if you later decide other AR models also should encrypt information. Better to add a non-AR class to work out the details. Andrew -- 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.
