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?

2 Answers 2


"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).

  • This has cleared up my confusion in a very satisfying way, thank you! a lot of terms collide and I'm glad I asked to clear this up.
    – Goose
    Aug 4, 2017 at 15:39
  • Great explanation !! Aug 4, 2017 at 16:41

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.

  • So I shouldn't feel bad about using models to handle more logic, such as manipulating data or calculating values? I was under the impression Models ideally only to be used to interact with the database, such as where the ORM logic goes.
    – Goose
    Aug 4, 2017 at 15:03
  • The Model should be used for everything that the View and the Controller are not responsible for. You can put business logic in there, long-running background tasks, whatever. Aug 4, 2017 at 15:15
  • 1
    That's good to know. A bit of a follow up question. I feel like ORM database interaction should be separated from the rest of the logic. Is there a design pattern to keep these concerns separated?
    – Goose
    Aug 4, 2017 at 15:18
  • 1
    Your ORM should already speak CRUD. Add a Business Logic Layer or Service Layer that converts business operations to CRUD transactions, and vice versa. Aug 4, 2017 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.