MVC (Model, View, Controller) is one of the most popular architectural terms in web development.
But here’s the uncomfortable truth:
MVC doesn’t fully describe how modern web applications actually work.
It explains separation of concerns, but it doesn’t explain execution flow. And that distinction matters.
The Missing Piece in MVC: Routing
In every modern web application, nothing happens without routing.
Before a controller runs.
Before a model is touched.
Before a view is rendered.
A request must first be matched to a route.
Yet when we say MVC, routing is completely invisible.
This creates confusion, especially for beginners, because the real request flow looks more like this:
Request → Router → Controller → Model → View
Not MVC.
Introducing RCMV
RCMV stands for:
Router
Controller
Model
View
In that order.
RCMV doesn’t replace MVC; it extends it to reflect how modern applications actually respond to requests.
What Each Part Does (In Reality)
Router
The true entry point of the application. It decides what code should respond to a request and whether that request is even allowed.
Without routing:
No pages load
No APIs respond
No CRUD operations happen
Controller
Activated only after the router allows it. Controllers coordinate the request, validate intent, and delegate responsibility.
They don’t own data, they orchestrate it.
Model
Responsible for structuring and managing data:
Relationships
Rules
Persistence
Business constraints
Models don’t respond to users; controllers do.
View
The final destination.
This is where structured data becomes something users can see and interact with.
The quality of the view depends entirely on how well the other layers were designed.
Why RCMV Is Useful
RCMV aligns better with:
The actual request lifecycle
How frameworks like Laravel, Django, Rails, and Express work
How developers debug real-world issues
How teams avoid spaghetti code
It also fits naturally with DDD-style thinking and cleaner system design.
Important Clarification
RCMV is not an attack on MVC.
It doesn’t change how applications are built.
It doesn’t “kill” MVC.
It simply provides a more accurate label for how modern web applications function.
Final Thought
MVC explains responsibilities.
RCMV explains reality.
Both matter, but we should be honest about which one we’re teaching.
What do you think?
Is MVC enough, or does modern development need a better mental model?
Top comments (1)
While I agree MVC is too simple of a concept to separate the concerns in an application. I think RCMV is not better.
You started good with
The one thing you forgot is response at the end. The view is only the data-formatter.
Basically a web application lifecycle is request in -> response out.
The router is nothing more than a ledger to connect specific request data to an application functionality. While it is an important piece of the puzzle, it is not the part that can explode in complexity.
As I mentioned before the view takes raw data and transforms it to suit the need of the expected response. The complexity of the view comes from the flexibility to create the view in multiple situations, not from the view itself.
The most difficult are the concerns of the controller and the model. In the MVC pattern the business concerns are bound to the model. But that is a bad collection of concerns. A better way is to split business concerns and data storage concerns.
This is also the reason people added business concerns in the controller, because they didn't identify them as business concerns.
If you want a linear representation I think it is: request -> router -> (controller (business/data storage/view)/view) -> response. I think each term to identify the complexity of a the request-response lifecycle is doomed to failure.