> 2. Your controller is meant to be simple glue between model and view - if you're putting tons of code in there, you're doing it wrong.
Yes, fat models are the way to go. This is just a good rule of thumb for any MVC framework. I feel like no framework docs actually explain this. Newbies end up shooting themselves in the foot because they don't understand the reason for separation or understand where logic should be implemented.
That's very debatable, and pretty rails-specific, IMHO. Conventional wisdom in other ecosystems is instead to have a business logic layer between your controller and your persistence layer. I've always found this to be good advice, as it makes the code more testable and makes reasoning about manipulating different models in the same operation easier.
Yes, fat models are the way to go. This is just a good rule of thumb for any MVC framework. I feel like no framework docs actually explain this. Newbies end up shooting themselves in the foot because they don't understand the reason for separation or understand where logic should be implemented.