Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Zen and the Art of the Controller

Zen and the Art of the Controller

So you’re fresh out of boot camp or just off a month long binge on RoR tutorials/examples and you’re feeling pretty good about MVC and how controllers fit into the whole framework. But projects in the wild are often far more complicated than you’ve been exposed to. In this talk, we’re going to discuss several techniques used by seasoned engineers to build and refactor controllers for features you’ll actually be working on.

C592d0867f891df9e8447b62459eb0c0?s=128

Michael Kelly

May 04, 2016
Tweet

Other Decks in Programming

Transcript

  1. Zen and the Art of the Controller Rails Controllers Beyond

    Bootcamp @thebadmonkeydev
  2. None
  3. Full-Stack Rails Controller Actions: 1. Index 2. Show 3. New

    4. Create 5. Edit 6. Update 7. Destroy
  4. So how does this happen? Usual Suspects: 1. Changing requirements

    2. Feature growth 3. Changes to the developer/team 4. Refactors from other areas of the app What really happened: A misunderstanding what resource an action is ACTUALLY dealing with
  5. Example: Social Ad SaaS Tool Requirements: • A tool to

    browse, read, add, edit, and delete ads on a social platform • Ads can be paused, activated, or archived • Users must be able to view their ads’ performance
  6. AdsController Basic BREAD (or CRUD) on Ad objects 1. Index

    2. Show 3. New 4. Create 5. Edit 6. Update 7. Destroy Action Count: 7
  7. But wait... We need to control these Ads on the

    Social Network
  8. AdsController Job Actions to Change Ad Status 1. Pause 2.

    Activate 3. Archive Action Count: 10
  9. Said by every exec, everywhere: Can we make the UI,

    I don’t know, cooler...you know...with javascripts or something?
  10. AdsController UI Widget-specific Actions 1. Preview 2. Stats Action Count:

    12
  11. None
  12. AdsController Pages for Statistics 1. Audience 2. Dashboard Action Count:

    14
  13. None
  14. BREAK IT UP Break a controller up into smaller, more

    accurate pieces by looking at what kind of resource your actions are ACTUALLY working with
  15. Other Types of Controllers To Think About 1. Static or

    View Layer Controllers 2. Composite Controllers 3. Aggregate Controllers
  16. Static/View Controllers Controllers that only function to provide a static

    view or to provide front-end access to a “view” of your domain model
  17. Composite Controllers A controller that works with ephemeral resources like

    Sessions or Jobs
  18. Aggregate Controllers Used to control data represented by several models

    or computed values
  19. AdsController Basic BREAD on Ad objects 1. Index 2. Show

    3. New 4. Create 5. Edit 6. Update 7. Destroy
  20. Why do we do this? 1. Easier Debugging and source

    navigation 2. Learning and Onboarding 3. Localized/Domain changes 4. Easier to coordinate large teams working on the same code
  21. Questions/Comments? • Look at what your actions are ACTUALLY working

    on • Break up your controllers to keep them lean n’ mean The Takeaway Or after the talk @thebadmonkeydev