That's exactly what I do. Observers is a hack. Which part of MVC do they belong? Models? No. Controllers? No. And most definitely not views. I use observers in rare occasions when there's a cross-cut of some logic that doesn't belong to the business domain. For example, I would put some specific logging or reporting to GA there. Invalidating caches is another common choice.
If you end up using observers to set flags, send notifications, or God forgive, initializing objects, think again. Most probably, you are looking for Factory or a Service. I would create a app/services/create_user.rb and stick all logic of instantiating new user records, calling notifiers and doing everything else that belongs to the user creating workflow there. It becomes (a) reusable, and (b) testable. - Aleksey On Saturday, June 9, 2012 3:49:12 PM UTC+3, marsbomber wrote: > > Testability is one of the reasons I try to keep myself away from observers > or callbacks in general. > > What's wrong with introducing plain ruby classes that wrapping up all > those callback logics? Explicit over magics, no? > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/_5a48BpKJ-oJ. 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/rails-oceania?hl=en.
