Why do frameworks give more flexibility to models than controllers?

Question

I've always tried to keep models for direct database interaction only, and keep all the actual logic in the controllers. Usually, a framework or platform provides more flexibility to models and limits the freedom of controllers.

• Models are usually able to be called from multiple controllers.
• Models are usually able to be called from other models.
• In the case of Magento, CRONs can't be called on controllers.

It sometimes seems like frameworks want controllers to be an advanced router. I sometimes end up putting non database logic in Models, or using concepts like Helpers or a concept specific to the framework, neither of which I don't enjoy doing.

What is the advantage of not giving controllers the same freedom that models typically get? Should I be looking at MVC differently than I am?

Answer 1

"Model" in this context (and in the context of MVC, MVP, MVVM, etc.) is not something you use for database access. It is not a data model. It also doesn't refer to "view models" that you may find in some frameworks (those are part of the presentation layer).
It is a set of software components (whatever they may be) that models your domain (i.e. it is a software representation of relevant aspects of the real-world domain).

This means that it is the Model that actually implements the core behavior of the system. It's in the Model where the actual bare-bones behavior of the system resides (and so you would expect it to contain non-DB logic). Everything else, including views, controllers, and even database access, is something you "attach" onto the Model. The direction of the dependencies should be towards the Model. Basically, in layered architecture, the Model is a part of the business logic layer (BLL), or in simpler systems, it is the BLL.

The Controller's job is to figure out how to engage the Model based on user input, and to translate data coming from the Views into a format that's better suited for the Model.

On the other side of the BLL you have DB access though a component (Gateway, Repository) that encapsulates data access, and if necessary translates data from the format passed on from the BLL, to a format that's expected by the DB (or an ORM). It also depends on the BLL (dependency inversion).

Answer 2

Because business logic is not one of the responsibilities of controllers, and MVC is all about separation of concerns.

You're not looking at this right. The whole point of MVC is to provide a mechanism for managing your UI separately from your Model. By deferring all other concerns to the model, MVC is allowing you the freedom to architect your model any way you wish.