I'm learning to implement RESTful APIs, and the concepts of Controller and Router are common in many frameworks, along with the MVC pattern in general, so I'm encountering them everywhere.
From this question and googling around I understand that they are not the same thing, as they are responsible of very specific, and different, actions. But one thing isn't clear: design-wise, is the router considered part of the controller?
In the mentioned question, one user comments:
You only need a model (database), a controller (which is the router), and the view (a page). That's it. If you have a Router and a Controller then you've over complicated it and are just using the Router to pass data to a Controller. A Controller is a Router, but a Router is not a Controller.
I often see routers and controllers on the same file, but it's very common to separate them in different files and/or directories. From this I understand that they are intimately related, but sometimes it's better to separate them to implement separation of responsibilities, and to make our codebase modular and easier to maintain.
Also in the mentioned question, we can see answers considering the router part of the controller layer, but others treating it as a different entities. Both can make sense in a thought experiment:
- Maybe you consider the router to exist before the MVC, as in one MVC per page. The router maps to the controller, but it's not considered part of the controller itself.
- Maybe you consider the router to be part of the controller, as in the whole webpage is one monolithic implementation of MVC. The router maps to the controller because one is part of the other.
This scenario is very subjective, but in the context of software architecture and design, is the MVC pattern more specific or clear about the roles and structure of routers and controllers?
In other words, is the router a module inside the controller, or is the router considered a separate actor (MVCR perhaps)?
Best Answer
How to you write the word "computer" in ancient latin language? Nobody knows, because for sure, there were no computers in the roman empire ;-)
The MVC architectural model was designed in the 70s to address a clean separation of responsibility and decoupling the "application" logic (Model) from the user interface (Views for the display, Controller for the input).
When we come to distributed architectures, we have a couple more concerns to add to our architectural design. Since routing was obviously not relevant in early MVC, you have the choice: