MVC Request Flow

How a browser request moves through the framework from IIS and the front controller, into routing, through the controller and model, and finally out as a rendered view.

Request Flow

Browser Request
      ↓
IIS / web.config
      ↓
public/index.php
      ↓
Router
      ↓
Controller
      ↓
Model
      ↓
View
      ↓
HTML Response
      ↓
Browser Output

The Big Picture

The MVC request flow separates the application into clear responsibilities. The controller handles the request, the model works with data, and the view renders the final output sent back to the browser.

  • Model handles data and database work
  • View handles presentation
  • Controller coordinates the request and response

Step-by-Step Flow

1. The browser sends a request

A user visits a URL such as /posts/5. The browser sends that request to the server.

2. IIS receives the request

IIS checks whether the request points to a real file or folder. If it does, IIS serves it directly. If not, the request is rewritten to the front controller.

3. The front controller starts the application

The request enters public/index.php, which acts as the single entry point for the MVC application.

4. The router matches the request

The router compares the request path and HTTP method against the route table and determines the correct controller and action.

5. The controller handles the request

The controller acts as the coordinator. It decides what data is needed, which model methods to call, and which view should be rendered.

6. The model works with data

The model performs data operations such as querying, inserting, updating, or deleting records, then returns the result to the controller.

7. The controller passes data to the view

Once the data is ready, the controller sends it to the view so the page can be rendered for the user.

8. The view renders the HTML

The view takes the data and builds the page output, including headings, text, links, buttons, and layout structure.

9. The browser receives the response

The rendered HTML is sent back to the browser, and the user sees the completed page.

Example End-to-End Flow

A request for /posts/5 may move through the framework like this:

/posts/5
   ↓
index.php
   ↓
Route match
   ↓
PostsController::show(5)
   ↓
Post::find(5)
   ↓
posts/show.php
   ↓
HTML sent to browser

Example Controller to Model to View

A simplified request might look like this in code:

$post = Post::find(5);

$this->view('posts/show', [
    'title' => $post['title'],
    'post'  => $post
]);

Responsibility Map

Model       = Data
View        = Display
Controller  = Coordination

Or more fully:

Model       = Database and records
View        = HTML presentation
Controller  = Request handling and flow control

Why This Flow Is Valuable

This design makes the framework easier to understand because each part has a clear role. It also helps the application grow in a clean and organized way.

  • Better organization
  • Easier debugging
  • Cleaner code structure
  • Reusable controllers and views
  • Safer long-term growth of the project

Key Idea

A request does not jump straight from the browser to the page. It moves through a structured path: Request → Router → Controller → Model → View → Response.

Snapshot Summary

  • The browser sends a request
  • IIS forwards application routes to index.php
  • The router finds the correct controller and action
  • The controller manages the request
  • The model retrieves or updates data
  • The view renders the final page
  • The browser receives the HTML response