Craig, I'm by no means an expert but I'm working on some different testing strategies. I'd be interested to have a peek at railscamp.
Andrew Sent on the run. On 15/06/2012, at 8:13, Craig Read <[email protected]> wrote: > Aleskey, > > I think that's a fairly simplistic view of Rails. > Rails itself is made up of a lot more design patterns than Model, View and > Controller. > And I reckon you'd be hard pressed to put together any half-decent rails site > only using those patterns. > > But as you implied, you need to use the right pattern for the right situation > though. > A service may be more appropriate for what I'm doing, but I'm not sure what > benefits it would give me over the Observer in this situation. > I'd still end up calling the service from callbacks in several different > models whereas the one Observer can watch all those models and respond. > > Nicholas, > > The after_save callback is exactly what the Observer is doing. > However, in this instance, I want to update 2 models with the cached results > of a calculation involving data from those and other models. > Rather than have the after_save in each model and increase coupling between > them, I put it all in a single observer that can watch all those models. > > I'll have my laptop with the source at RailsCamp if anybody is keen enough to > take a look and provide feedback. > > Cheers, > > Craig. > > On Mon, Jun 11, 2012 at 12:04 AM, Aleksey Gureiev <[email protected]> wrote: > 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. > > > > -- > Craig Read > > @Catharz > https://github.com/Catharz > http://stackoverflow.com/users/158893/catharz > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" 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/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
