On 20 June 2011 01:15, John SB <[email protected]> wrote: > I have a basic stylistic question I would like some feedback on. > > I have a table containing messages, each message has a status of > current or expired. > > Messages expire a set period after they were created. Right now I > have a function in my controller to get the current message. This > function also has the expiration logic built into it. > > Get Current > msg = Message that is marked current in the DB. > if msg == nil > return nil > end > if msg.hasExpired? > Set message to expired in DB > return nil > else > return msg > end > end > > So I was thinking it would be useful to put this in my model. I could > add a method to the model called getCurrent that had this exact > logic. I could also put the expiration logic in an after_find > callback. > > But this seems like business logic so I'm not sure this is a good > idea? Should this stay in the controller, if I put in the model what > approach is best.
Expiring messages is certainly business logic so it should go in the model not the controller. You could put the code in an after_find callback in the model so it is run every time a record is fetched. However if the decision as to whether a message is expired or not is entirely based on the time since creation there may be no need for a column in the database. Simple add a method to the model, something like def expired? Time.now - self.created_at > 10.days # or whatever the period is end Colin -- 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.
