ActiveRecord without active record

I discuss techniques to use the very popular and well maintained open source
ActiveRecord rubygem, while avoiding the active record pattern due to common
pitfalls it creates for larger projects. We'll use some different techniques to
refactor a simple application with the ultimate goal to remove the usage of the
active record pattern where possible.

Transcript

2. ActiveRecord without active record @mariovisic
3. @mariovisic Lead maintainer of howgoodischeese.com
6. Let’s talk about active record the pattern
7. • Named by Martin Fowler in 2003 • Logic and data all stored together in one class active record
8. active record user.rb class User < ActiveRecord::Base # Database columns gain # getters and setters # attributes id, username, full_name # Instance methods add logic def display_name if full_name.present? full_name else username end end # Class methods return collections # of objects def self.admins where(admin: true) end end users integer id varchar username varchar full_name bool admin
9. active record is a great pattern … for prototyping small projects that won’t change much
10. Let’s talk about ActiveRecord the rubygem
11. • Most popular ruby ORM • Implements the active record pattern • Original implementation by David Heinemeier Hansson (now many contributors) • Logic and data all stored in one place • Works great for small projects
12. • Convention over configuration • Type coercion • Validations • Great DB query interface ActiveRecord is really nice
13. Let’s look at some code Written using the active record pattern
15. Callbacks aren’t great They make it more difficult to easily build a mental picture of how the code works
16. Being explicit is better class User < ActiveRecord::Base # … def save send_welcome_email bust_global_users_cache do_some_other_important_things end # … end It’s easier to build a mental model of the code when it’s explicit in describing behaviour
17. What method do I use to update an attribute on a model and run the callbacks, but not the validations?
19. Logic on models creates dependencies in the wrong direction
20. “Depend on things that are more stable than you are” - Sandi Metz
21. User Welcome email User is a core of the application and considered more stable than a welcome email. This means that it’s better for our welcome email to know about a user, rather than a user knowing about a welcome email. Dependencies
22. Dependencies … … … comment item user welcome email user session registration app … Changing welcome email, user session or login is hard without touching the user … … … … … … … … … … … … …
23. Dependencies … … … comment item user welcome email user session registration app … … … … … … … … … … … … … … Changing welcome email, user session or login is easier without touching the user
24. Development speed Time speed start future quick slow active record Ideal
25. Let’s change some code To no longer use the active record pattern
27. To Recap By avoiding the active record pattern we have:
28. • Separated business logic into smaller classes that are easier to reason about • Changed our dependencies to be in the correct direction, less stable -> more stable, ensuring we can easily modify our application as it grows • Avoided callbacks to be more explicit about our logic to allow us to more easily build a mental picture of our codebase • Moved web user validations to a layer that doesn’t affect other kinds of users (console)
29. Thanks, any questions? @mariovisic