I have to second what Petr says. Business logic should never go inside a model. It often involves juggling with different models, external services, jobs and whatnot. Are you suggesting to push it all into models so that a post (for example) had the knowledge of some email sending functionality that it had to invoke when it's created? Absolutely not. Models are mostly DTOs providing their data manipulation and transformation as additional methods.
Then where does the logic go if it's not in the models? Who can have this knowledge of everything business-involved in your system? Controllers? No. And here's why. Controllers are there for processing your HTTP requests -- converting inputs, invoking operations and rendering outputs. Assume that you have other channels your requests for operations come in -- CLI, Websockets, queues... Are you going to duplicate your business logic across all of them? The sane architectural decision is to move all your business logic into a separate layer between your input channels (Rails controllers, for example) and your data layer. Here's where PORO, service objects, interactors, commands (however you call them) come into play.
Of course, everyone is entitled to do whatever they like with their apps. Unfortunately with modern languages and everyone jumping on the cool coding train without classical software engineering education we have a lot of programmers with no idea how to properly architecture their products. My suggestion to everyone looking to make themselves a better programmer is to take time to read works by Martin Fowler, Kent Beck, Robert Martin and others. Time well spent. Peace!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have to second what Petr says. Business logic should never go inside a model. It often involves juggling with different models, external services, jobs and whatnot. Are you suggesting to push it all into models so that a post (for example) had the knowledge of some email sending functionality that it had to invoke when it's created? Absolutely not. Models are mostly DTOs providing their data manipulation and transformation as additional methods.
Then where does the logic go if it's not in the models? Who can have this knowledge of everything business-involved in your system? Controllers? No. And here's why. Controllers are there for processing your HTTP requests -- converting inputs, invoking operations and rendering outputs. Assume that you have other channels your requests for operations come in -- CLI, Websockets, queues... Are you going to duplicate your business logic across all of them? The sane architectural decision is to move all your business logic into a separate layer between your input channels (Rails controllers, for example) and your data layer. Here's where PORO, service objects, interactors, commands (however you call them) come into play.
Of course, everyone is entitled to do whatever they like with their apps. Unfortunately with modern languages and everyone jumping on the cool coding train without classical software engineering education we have a lot of programmers with no idea how to properly architecture their products. My suggestion to everyone looking to make themselves a better programmer is to take time to read works by Martin Fowler, Kent Beck, Robert Martin and others. Time well spent. Peace!