MVC responsibilities — PHPAML Documentation

Three jobs, three names.

MVC summarizes three roles. They are not three separate programs: they are three ways to organize work inside the same application.

MModel: what the application knows

The book title, its author, and the rule determining whether it is available.

VView: what the person sees

The title, cover, and button displayed in the browser.

CController: what connects the two

It receives number 12, asks for that book, then selects the page to display.

Example: display our book.

phpaml — zsh

'GET /books/{id}' => [BookController::class, 'show']

phpaml — zsh

public function show(Request $request): Response
{
    $book = $this->books->find((int) $request->attribute('id'));

    if ($book === null) {
        return Response::html('<h1>Not found</h1>', 404);
    }

    return $this->view('books/show.php', ['book' => $book]);
}

The route knows the address and action. The controller converts the identifier, asks the repository for the book, handles absence, then chooses a view. The view receives a book ready to display.

Read the controller line by line.

1

show receives the request already recognized by the router.

3

The URL identifier is converted to an integer, then passed to the repository.

5

The controller accounts for a missing book.

6

It then selects an explicit 404 response.

9

Otherwise, it gives the book to the view; it does not build HTML itself.

Recognize a misplaced responsibility.

SQL inside a view

The view then knows storage details and becomes hard to test.

HTML inside a model

The model can no longer serve an API or another presentation.

Everything in the controller

Business rules become long, duplicated, and hard to reuse.

MVC is not alone: three complementary roles.

As the application grows, some work fits neither a model, view, nor controller. It receives a precise name instead of making controllers artificially large.

Service

Performs a business operation combining several steps, such as borrowing a book and sending confirmation.

Repository

Retrieves or stores data without exposing storage details to the controller.

Middleware

Runs before or after the controller for a shared rule: authentication, security, or logging.

Validation

Checks that received information exists and follows the expected format.

A simple rule for deciding where code belongs.

It concerns the address or HTTP methodRoute

It organizes the answer to a requestController

It describes data or a business ruleModel / service

It chooses what is displayedView

It applies to many requestsMiddleware

Why not put everything in one file?

AT FIRST

One file feels faster: read the URL, query the database, and write HTML in one place.

AS THE PROJECT GROWS

Rules get copied, tests require a whole page, and a visual change risks touching data. MVC pays off when the second feature arrives.

BEGINNER QUESTIONS

You may be wondering…

Is MVC mandatory for every small program?

No. A very short exercise can fit in one file. Separation becomes useful when a project has several pages or rules.

Is a model always a database table?

No. It mainly represents domain data or a rule. It can exist before any database.

Does a view always contain HTML?

In a classic application, often yes. In AML View, it can be described with PHPAML View's PHP components.

CHECK YOUR UNDERSTANDING

Who should verify that a discount is allowed: the view or business domain?

Show the answer

The business domain, usually in a model or service. The view only presents the result.

YOUR TURN

For borrowing a book, assign these tasks: check availability, read the URL identifier, display the Borrow button.

Show a hint

Model/service: availability; controller: identifier; view: button.

SUMMARY

What to remember

The model owns data and business rules.
The view presents.
The controller coordinates.
Good separation reuses the same logic for HTML or JSON.