Ask and you shall receive. I kept my eyes open and discovered this resource by Avdi Grimm:
http://avdi.org/devblog/2011/11/15/early-access-beta-of-objects-on-rails-now-available-2/
In it, he covers some of the reason that Rails projects get so tightly coupled to both the framework and ActiveRecord. He uses TDD to assure loose coupling with techniques like
- Dependency Injection
- Presenters
- Strategy Pattern
- DCI
It provides a good start to answering this question in a practical way. (It costs $5 for the early beta but will eventually be free.) In fact, it's the first resource I've found that does. Please add any others you find.
Here's the real gem that elucidates the heart of the problem:
One day, after years of witnessing and addressing the technical debt incurred in various maturing Rails codebases as a result of ActiveRecord-inspired tight coupling, I had an epiphany. What if we stopped treating ActiveRecord as the backbone of our model classes, and instead, programmed as if ActiveRecord were merely a private implementation detail?
Corey Haines puts it another way:
I pull the behavior out of my models into other objects that wrap the models.
I prefer to make the AR objects simple wrappers around the db-access stuff in AR.
I have a fairly strict rule that controller actions cannot use AR finders or,
in fact, interact with AR at all. AR should be accessed within api methods
inside your model, not from the outside.
