Rails as a piece of birthday cake

Ruby on Rails as a framework follows the Model-View-Controller design pattern.

Vladimir Dementyev

Principal Engineer at Evil Martians

Schedule Entry

Slides

Attendees

• Reed
• Jeremy
• Josh

Relevancy	Interesting
9, 9, 9	8, 9, 9

Notes

• MVC review
  • Model = state / logic
  • View = user interface
  • Controller = translating user input to model updates
• Model -> view ?
• Model -> ui?
• MVC cake
  • 3 layers ok for small
  • Not ok for big
  • New layers needed for bigger cake. Scale the # layers
• Beyond MVC cake
  • More sophisticated but sufficient architecture
• Vladamir
  • Check out “Rails Changelog” podcast
• Rails Way is to build Web application = serves http requests with responses
• To increase code maintainability
  • Complexity
  • Testability
• How to add new abstraction layer without adding complexity?
  • Good abstractions decreases complexity
  • Bad abstractions increases complexity
  • Think of tetris pieces fitting together
• Good abstractions
  • Conventions - try to make your convention non-orthogonal to Rails conventions. Make it look like it * belongs to rails. (principle of least surprise)
  • Loose coupling
  • Encapsulation
  • Single Responsibility (or a few related ones)
  • Simplification
  • Generalization
  • Centralization
  • Reusability
• Recipe step 1: Rails conventions. Learn how Rails works, re-use Rails building blocks & patterns.
• Layered Architectures - layers only depend on those below it. Sometimes can depend upon layers much deeper than next one.
  • Presentation
    • Controllers
    • Views
    • Channels
  • Application
    • Jobs
    • Mailers
  • Domain
    • Models
  • Infrastructure
    • DB adapters
    • Rails secret key base
• Object belongs to highest arch layer among all its inputs
• Recipe step 2: Layered architecture ideas
• How to choose new abstractions? => How to extract abstractions?
• Recipe step 3: codebase extracts, no artificial concepts. Perform complexity analysis, analyze and extract abstractions.
• Service objects are pseudo abstraction layer
  • app/services - bag of random objects
  • No generalization
  • No consistency
  • Intermediate stage until the final abstraction emerges
  • Like a waiting room until next abstraction emerges/arrives
  • Good generalization requires some aging
• Form Objects
  • For processing form submissions
  • Making Rails abstraction via type casting, validations
  • Trigger side actions on successful submission
  • Can make it work as a model in views/forms!