Skip to content

Comment on On logic in a Rails app, revisited 6 years later

Comments

A lot of discussion I heard around writing idiomatic Rails led to really fat models. Given the number of database trips back and forth with ActiveRecord, it didn't end well.

Eventually as the system grew it was much better to have bulk-interfaces of data-only for reads that completely bypassed ActiveRecord. Logic in controllers was also eventually factored out and re-used elsewhere.

My experience is that a lot of advice for Rails centers around small-to-medium size applications, and of course practices that are efficient and practical for apps of that size might not work exceptionally well in other scenarios.

A number of years ago I started decoupling my business logic from my controllers and models and now use the ActiveInteraction gem. It really makes a difference when you have multiple interfaces that need to deal with a specific action on a specific object without having to call a controller all of the time.

While idiomatic Rails is definitely possible, I've been bitten by coding errors in Models where specific validations are only ran on update and/or create. Now I just run a CreatePerson object which only has the specific functionality needed and is decoupled as much as possible from other sections.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.