RubyTapas Episode 21: Domain Model Events

Posted on
November 12, 2012

by
Avdi Grimm

Today’s free Monday episode features a rare delving into Rails code. We take a look at a fat controller, and thin it down by identifying the model lifecycle events that are hiding inside it.

This episode garnered a lot of discussion after I initially sent it out to RubyTapas subscribers. Ryan Bates posted an alternative refactoring, as did Evan Light.

Like what you see? This is just a taste of RubyTapas! Sign up today to get three videos a week, along with full source code and transcripts.

Subscribe Now!

Or click here to learn more.

Related posts:

  1. RubyTapas Episode 10: Finding $HOME
  2. RubyTapas Episode 4: Barewords
  3. RubyTapas Episode 7: Constructors
  4. RubyTapas Episode 13: Singleton Objects
  5. RubyTapas Episode 1: Binary Literals
This entry was posted in Rails, Ruby, RubyTapas Samples, Screencasts. Bookmark the permalink.
  • http://railscasts.com Ryan Bates

    Thank you for making this episode free Avdi, it has brought about some fun discussion on Twitter. Regarding my refactoring, it was more of an experiment to see how it could be done without using callbacks. I do think callbacks are a good use case for this.

    Also, Jonas Nicklas pointed out there is a previous_changes method that dirty tracking provides. This could be used to clean up each of our refactorings.

  • jamel

    Hi Avdi great video. Please I wanted to find out why you chose to create the methods to enable add_listener and notify_listeners etc, can we just use ActiveSupport::Notification instead since it provides a kind of light weight pub-sub.

    I am looking to use ActiveSupport::Notification to communicate between my domain objects. I know another way round is ActiveRecord observers but I don’t want to use it because it will be removed from rails-4 and moved into a gem and eventually they will stop updating/maintaining the gem. So that rules it out and leaves me with ActiveSupport::Notification.

    What is your thought, on using ActiveSupport::Notification for this sort of thing. Are there any implications?

    Keep up the good works and thanks for the response you shall provide.

    • http://avdi.org Avdi Grimm

      ActiveSupport::Notifications, as I understand it, is intended mainly for instrumentation and I’d rather use it for that purpose only. Also, for some problems Observer is sufficient; a full pub/sub framework isn’t really called for.

      • jamel

        thanks.