Rails vs. Object Oriented Design
summary
Rails encourages quick CRUD but often produces fat ActiveRecord models that mix persistence, presentation and payment logic; a real project showed a 1:2.5 code:test ratio, five test suites and 180 attendees as context. Practical fixes: extract an order_process + payment objects pair so payments are polymorphic and reusable in a GUI, wrap presentation in a presenter/decorator (Draper) to keep views thin, use custom validators and custom responders in Rails 3, and add folders via config.application.rb to hold plain Ruby objects.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 0:54Tom Stuart
- 3:11Disclaimer
- 8:59ActiveRecord
- 14:47View Layer
- 18:38View Decorator
- 19:33Custom Validators
- 24:20Further Reading
- 25:03Questions
related talks
46mRails as a piece of birthday cake
41mOff the Tracks - Challenging the Rails Mindset
39mExploring Rails anti-patterns
32mRails Sustainable Productivity
31mIf it bleeds, it leads
41mAPPLICATION ARCHITECTURE: BOUNDARIES, OBJECT ROLES, & PATTERNS
38mRails hurts, because you're using it wrong. Let's fix that
01h 09mRails 3 ...and the real secret to high productivity