On logic in a Rails app, revisited 6 years later

Post by karmakaze » Sun, May 19, 2019, 4:02 PM UTC

drchiu wrote: post #20

archey1 wrote: post #17

Been doing Rails development for 6+ years. The most maintainable codebases I've worked on had some kind of service layer between the controller and the model. We used the "interactor" gem to create individual units of business logic that we could reuse and piece together into larger "flows". Business logic stayed in the interactors, persistence logic in the models. This lead to skinny controllers, skinny models and m…

My team discovered the interactor pattern about 8 months ago and never looked back. It’s worked extremely well and easy to read. We’ve found it necessary to maintain a sensible naming convention for the interactors and to namespace them. The other pattern we’ve found to work decently well is to ensure most operations are idempotent. It makes it easy to ensure the correct state.

Post by richjdsmith » Sun, May 19, 2019, 7:23 PM UTC

mercer wrote: post #29

burlesona wrote: post #16

I've found that a pretty simple technique along the lines of what's shared in the article makes complex Rails apps much more maintainable. Most of this applies to any MVC style app/framework. I follow these rules of thumb: 1. Controllers should only handle converting HTTP to ruby calls. That includes logic that is specific to the request flow, like parsing params or authenticating cookies, but nothing else. 2. Models…

> 3. What Rails calls "views" should be though of as simple html templates with loops and simple if/else, but no complex logic. I rather like how Phoenix makes a clear separation between views and templates. The templates have no logic, but the views can have quite a bit of it as long as it is directly linked to the templates (presentational).