Finalizing MVC Integration: Connecting Your PHP Architecture

Previously in this course, we explored The Front Controller Pattern: Centralizing PHP Request Handling to route traffic, and established our Project Structure Strategy: Organizing Your PHP MVC Application. Now, we are connecting these pieces into a unified system.

In a mature web application, the Model-View-Controller (MVC) pattern is not just a folder structure; it is a workflow. To achieve true MVC integration, your components must talk to each other through well-defined interfaces rather than reaching across layers.

The Request Lifecycle: Connecting the Dots

Think of your MVC architecture as a relay race. Each component has one job, and it must pass the "baton" (data) to the next player without dropping it.

1. Router: Identifies the request and calls the appropriate Controller method.
2. Controller: Orchestrates the process. It asks the Model for data and then passes that data to the View.
3. Model: Interacts with the database or business logic, returning pure data (usually as arrays or objects).
4. View: Receives the data and handles the final HTML output.

Worked Example: The "Show Product" Flow

Let’s see how this looks in practice. We are building a simple product catalog.

The Model (app/Models/Product.php) Your model should focus solely on data retrieval. It shouldn't know anything about the browser or the URL.

PHP
namespace App\Models;

class Product {
    public function find(int $id): ?array {
        #6A9955">// In a real app, you'd use PDO here(as covered in lesson 23)
        $products = [
            1 => ['name' => 'Mechanical Keyboard', 'price' => 150],
            2 => ['name' => 'Gaming Mouse', 'price' => 80]
        ];
        return $products[$id] ?? null;
    }
}

The Controller (app/Controllers/ProductController.php) The controller is the glue. It receives the ID from the router, fetches the data from the model, and hands it off to the view.

PHP
namespace App\Controllers;

use App\Models\Product;

class ProductController {
    public function show(int $id) {
        $model = new Product();
        $product = $model->find($id);

        if (!$product) {
            http_response_code(404);
            require 'views/404.php';
            return;
        }

        #6A9955">// Pass the data to the view
        require 'views/product.php';
    }
}

The View (views/product.php) The view is strictly for display. It uses the $product variable injected by the controller.

HTML
style="color:#808080"><style="color:#4EC9B0">h1>Product Detailsstyle="color:#808080"></style="color:#4EC9B0">h1>
style="color:#808080"><style="color:#4EC9B0">p>Name: <?= htmlspecialchars($product['name']) ?>style="color:#808080"></style="color:#4EC9B0">p>
style="color:#808080"><style="color:#4EC9B0">p>Price: $<?= $product['price'] ?>style="color:#808080"></style="color:#4EC9B0">p>

Why This Architecture Matters

By keeping these layers separate, you gain the ability to change one without breaking the others. If you decide to switch from a MySQL database to a JSON API, you only change the Model. If you want to change your site's design, you only change the View.

Following Refined Template Separation: Layouts and Partials in PHP ensures your views stay clean, preventing the controller from becoming a dumping ground for HTML logic.

Hands-on Exercise

1. Create a UserController with a profile method.
2. Create a User model that returns a hardcoded array of user data (e.g., ['username' => 'dev_student', 'email' => 'dev@example.com']).
3. Modify your router.php to map a URL like /user?id=1 to your UserController@profile method.
4. Render the user data in a views/user_profile.php file.

Common Pitfalls

• Logic in Views: Never perform database queries inside a view file. If you find yourself writing new PDO(...) inside a .php file in your views/ folder, stop immediately—that belongs in the Model.
• Controller Bloat: If your controller exceeds 50–100 lines, you are likely doing too much. Extract business logic into "Service" classes or helper methods.
• Hardcoding Paths: Use constant base paths for your require statements to avoid breaking your site when you move files between subdirectories.

FAQ

Can a View talk directly to a Model? In strict MVC, no. The Controller acts as the mediator. Allowing the View to access the Model creates "tight coupling," which makes your code harder to test and debug.

What if my Controller needs to redirect? That is perfectly fine! The Controller is the only layer that should handle HTTP-specific actions like redirects or setting headers (which we touched on in lesson 17).

Recap

We’ve successfully connected the layers: the Router dispatches to the Controller, the Controller coordinates the Model's data with the View's presentation, and the View outputs the result. This workflow is the foundation of every professional PHP web application.

Up next: We will explore how to monitor and fix your code with Debugging PHP Applications.