The controller is not the whole application.
Represents data and business rules. It does not decide button color.
Presents information. It should not execute an SQL query.
Receives the use case, calls what is needed, and chooses the response.
Example: display a product.
'GET /products/{id}' => [ProductController::class, 'show']public function show(Request $request): Response
{
$product = $this->products->find((int) $request->attribute('id'));
if ($product === null) {
return Response::html('<h1>Not found</h1>', 404);
}
return $this->view('products/show.php', ['product' => $product]);
}The route knows the address and action. The controller converts the identifier, asks the repository for the product, handles absence, then chooses a view. The view receives a product ready to display.
Recognize a misplaced responsibility.
SQL inside a viewThe view then knows storage details and becomes hard to test.
HTML inside a modelThe model can no longer serve an API or another presentation.
Everything in the controllerBusiness rules become long, duplicated, and hard to reuse.
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.
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.