PHP MVC Architecture Explained: Building Maintainable Web Applications

What MVC Actually Solves

Model-View-Controller is not a PHP-specific idea, but it is the structural backbone of almost every modern PHP framework, including Laravel. Before MVC patterns became standard, a typical PHP page mixed database queries, business logic, and HTML output directly in the same file — functional, but increasingly unmanageable as a site grows past a handful of pages. MVC solves this by separating three distinct concerns so each can change independently.

The Three Pieces

Model

The Model represents data and the rules around it — typically a class mapped to a database table, responsible for fetching, validating, and saving its own data. A Model should not know anything about HTML or HTTP; it deals purely in data and business rules.

class Product {
    public function __construct(
        public readonly int $id,
        public readonly string $name,
        public readonly float $price,
        public readonly int $stock,
    ) {}

    public function isInStock(): bool {
        return $this->stock > 0;
    }
}

View

The View is purely presentation — it takes data handed to it and renders HTML, with no business logic of its own. A view deciding "if stock is low, show a warning" by directly querying the database itself is a sign the architecture has been violated; that decision belongs in the Model or Controller, with the View simply rendering the result.

Controller

The Controller receives the incoming request, asks the Model for whatever data is needed, makes any necessary decisions, and hands the result to a View to render. It is the coordinator, deliberately kept thin — a controller stuffed with business logic and raw SQL queries has effectively become the old "everything in one file" pattern again, just relocated.

A Minimal Working Example

// Model
class ProductRepository {
    public function __construct(private \PDO $pdo) {}
    public function find(int $id): ?Product {
        $stmt = $this->pdo->prepare('SELECT * FROM products WHERE id = :id');
        $stmt->execute(['id' => $id]);
        $row = $stmt->fetch();
        return $row ? new Product($row['id'], $row['name'], $row['price'], $row['stock']) : null;
    }
}

// Controller
class ProductController {
    public function __construct(private ProductRepository $products) {}
    public function show(int $id) {
        $product = $this->products->find($id);
        if (!$product) {
            http_response_code(404);
            return view('products.not-found');
        }
        return view('products.show', ['product' => $product]);
    }
}

// View (products/show.php)
// <h1><?= htmlspecialchars($product->name) ?></h1>
// <?= $product->isInStock() ? 'In Stock' : 'Out of Stock' ?>

Why This Separation Actually Matters

The practical payoff shows up over time, not on day one. A Model's business rules (like isInStock()) can be unit tested without rendering any HTML or hitting a real HTTP request. A View can be redesigned visually without touching any database logic. A Controller can be tested by checking what it asks the Model for and what it hands to the View, without needing a real database connection at all in many test setups. None of this is impossible without MVC, but the separation makes each of these things the default, rather than something you have to fight the codebase's structure to achieve.

Common Violations of MVC in Practice

• "Fat controllers" — business logic (validation rules, calculations, multi-step workflows) written directly inside controller methods instead of delegated to the Model layer or a dedicated service class.
• Database queries inside Views — a template file calling a query directly because "it was faster than passing the data down," which makes the view untestable without a live database and harder to cache.
• Models that know about HTTP — a Model method that reads $_POST directly or returns an HTTP response, coupling data logic to a specific delivery mechanism it should not need to know about.

Where Service Classes Fit In

As applications grow, a fourth informal layer often emerges: service classes that hold business logic too complex to live cleanly in either a Model or a Controller — an order checkout process that touches inventory, payment, and email notifications, for example. This is not a deviation from MVC so much as a practical extension of it; the Controller stays thin by delegating to a service, and the service coordinates multiple Models without becoming part of any single one of them.

MVC in Laravel Specifically

Laravel structures this directly: Eloquent models in app/Models, Blade templates as Views in resources/views, and Controllers in app/Http/Controllers, with routing in routes/web.php connecting incoming URLs to specific controller methods. Laravel also formalizes the "thin controller" idea further with Form Request classes for validation and dedicated Service or Action classes for business logic, both reducing how much logic naturally accumulates in a controller over time.

Step-by-Step: Refactoring a Mixed-Logic Script Into MVC

1. Identify every database query in the script and move it into a Model or repository class.
2. Identify every HTML output statement and move it into a separate view template, parameterized by variables passed in rather than computed inline.
3. What remains — reading the request, deciding which Model methods to call, choosing which View to render — becomes the Controller.
4. Any logic that does not cleanly belong to a single Model (multi-step processes, cross-cutting business rules) becomes a service class the Controller delegates to.

Frequently Asked Questions

Is MVC the only good architecture for PHP applications?

No — alternatives like hexagonal architecture or domain-driven design exist and suit certain complex applications better. For the large majority of business websites and web applications, however, MVC (as implemented by frameworks like Laravel) provides enough structure without excessive ceremony.

Does using MVC mean I cannot use plain PHP at all?

No — MVC is a pattern, not a specific framework. You can structure plain PHP code into Model, View, and Controller files yourself without adopting a framework, though a framework handles the routing and wiring that connects them so you do not have to build that plumbing from scratch.

Where do API endpoints fit into MVC?

The same Controller can often serve both a web View and a JSON API response, simply choosing what to return based on the request — though many applications split these into separate Controllers (web vs API) once both surfaces grow complex enough to diverge meaningfully.

Is it bad practice to query the database directly from a Controller for a simple case?

For a genuinely trivial one-off lookup, the practical risk is low, but the discipline of always going through the Model layer pays off the moment that "simple" query needs to be reused elsewhere, validated consistently, or tested independently of the HTTP layer.

Conclusion

MVC is not about following a rule for its own sake — it is about making a codebase's different concerns (data, logic, presentation) independently changeable, so a redesign does not risk breaking business logic and a business rule change does not require touching HTML. If your existing codebase has grown past the point where this separation is clean, we can help restructure it.

Testing Each Layer Independently

One of the clearest practical benefits of MVC shows up in testing. A Model's business rule (like a stock-checking method) can be tested with a plain unit test, no HTTP request or rendered HTML involved at all. A Controller can be tested by checking it calls the right Model method and passes the right data to the View, often using a fake or mock Model rather than a real database. Without this separation, testing business logic means simulating an entire HTTP request and parsing the resulting HTML just to confirm a calculation was correct — slow, brittle, and a strong discouragement from writing tests at all.

Case Study: A Codebase That Outgrew Its Original Structure

A common growth pattern: an application starts with simple, thin controllers and clean models, then over a year of feature additions, business logic creeps directly into controller methods because it is the path of least resistance for "just one more if statement." Eventually, a single controller method handles validation, multiple database writes, an email send, and a calculation, all inline — functionally working, but now untestable without a full request simulation and risky to modify without breaking something unrelated. The fix is usually introducing a service-class layer between Controller and Model specifically for that accumulated logic, rather than trying to force everything back into the Model itself, which often does not fit either.

Glossary

• Fat controller — a controller that has accumulated business logic it should have delegated to a Model or service class.
• Service class — a class holding business logic that spans multiple Models or is too complex to live cleanly in either a Model or Controller.
• Repository pattern — a common variation where database access is isolated into dedicated repository classes, keeping Models focused on business rules rather than query construction.

Frequently Asked Questions

How big should a Controller method be before I consider it too fat?

There is no strict line, but a useful heuristic: if a controller method is difficult to summarize in one sentence, or it directly contains validation rules, calculations, and multiple unrelated database writes, it has likely outgrown what a controller should hold.

Do single-page applications (SPAs) still use MVC on the backend?

Often yes, on the API side — an SPA frontend typically talks to a backend that still separates Models (data), Controllers (handling API requests), with the "View" effectively replaced by JSON responses consumed by frontend components instead of server-rendered HTML.

Is the Repository pattern required for proper MVC?

No, it is a common and useful addition, not a requirement — many MVC applications keep query logic directly inside Model classes without a separate repository layer, which is perfectly valid for simpler applications.

Step-by-Step: Structuring a New Feature Using MVC From Scratch

Walking through building a "favorites" feature end to end shows how the layers actually divide responsibility in practice:

1. Define the Model first — a Favorite class and a repository method to add, remove, and list a user's favorited items, with no awareness of HTTP at all.
2. Write the business rule as a Model method — for example, enforcing a maximum number of favorites per user lives in the Model layer (canAddMoreFavorites()), not scattered as an inline check in the Controller.
3. Build the Controller actions — store() to add a favorite, destroy() to remove one, each just calling the Model, checking the result, and choosing a View or redirect; no business rules duplicated here.
4. Create the View — a template that simply renders whatever list of favorited items the Controller handed it, with a heart icon toggling based on a boolean flag already computed by the Model, not recalculated in the template.
5. Wire the route — connect the URL and HTTP method to the Controller action, the piece that makes the other three reachable from a browser request at all.

Following this order — Model and its rules first, then Controller, then View — tends to naturally keep business logic out of the wrong layer, because the rule already exists in the Model by the time the Controller is written and there is no temptation to duplicate it there.

Comparing Architectural Approaches

MVC in the Context of Modern Frontend Frameworks

When a PHP backend serves a frontend built with React, Vue, or another JavaScript framework instead of server-rendered Blade templates, the "View" portion of MVC effectively moves to the frontend application entirely. The PHP backend keeps its Model and Controller layers, but instead of rendering HTML, the Controller returns JSON, and the frontend framework becomes responsible for turning that data into UI. This is sometimes called an API-first or "headless" architecture, and it does not abandon MVC so much as relocate the View outside the PHP codebase entirely — the same discipline around keeping business logic in the Model and coordination logic in the Controller still applies, just without a Blade template at the end of the chain.

How Much Structure Is Too Much for a Small Project

Not every project needs the full weight of MVC plus a service layer plus a repository pattern. A genuinely small, single-purpose internal tool used by three people may reasonably skip the more elaborate layering and keep things simpler, as long as that simplicity is a deliberate choice for the project's actual scope rather than an accident of never having thought about structure at all. The risk worth watching for is not "using too little structure for a small project" but rather a small project that quietly grows into a large one while still carrying its original "we'll structure it properly later" assumption, at which point the unstructured code has accumulated years of features on top of it.

Final Checklist for a Well-Structured MVC Feature

• Business rules and validation logic live in the Model (or a dedicated service class), not scattered inline in the Controller
• The Controller method can be summarized in one sentence: receive request, ask Model, choose View/response
• The View contains no direct database queries and no business decisions, only data already prepared for it
• Each layer can reasonably be tested in isolation, without needing to simulate the other two layers just to verify one of them works
• A new developer joining the project can predict, from the file structure alone, roughly where a given piece of logic should live

Dependency Injection and Its Relationship to MVC

As MVC applications grow, Controllers and Models increasingly depend on other classes — a database connection, an email sender, an external API client. Dependency injection is the practice of providing those dependencies to a class from the outside (typically through its constructor) rather than the class creating them itself internally. This matters for MVC specifically because it is what makes the testing benefits discussed earlier actually achievable in practice: a Controller that receives its Model dependency through its constructor can be tested with a fake or mock version of that dependency, while a Controller that instantiates its own Model directly inside a method cannot easily be tested without also exercising whatever that Model actually does internally, database calls included.

// Without dependency injection ÔÇö hard to test in isolation
class OrderController {
    public function store() {
        $repo = new OrderRepository(new PDO(...)); // creates its own real dependency
        $repo->save(...);
    }
}

// With dependency injection ÔÇö easy to substitute a fake repository in tests
class OrderController {
    public function __construct(private OrderRepository $repo) {}
    public function store() {
        $this->repo->save(...);
    }
}

Laravel's service container handles this wiring automatically in most cases, resolving a Controller's constructor dependencies behind the scenes, which is part of why Laravel applications tend to default toward this pattern without much extra ceremony required from the developer.

When a Project Outgrows Plain MVC Entirely

For most business applications, MVC (with an added service layer as needed) remains sufficient indefinitely. A smaller number of genuinely large, complex systems eventually benefit from more advanced patterns — CQRS (separating the code paths for reading data from the code paths for writing it), event-driven architectures (where actions trigger events that other parts of the system react to independently), or full domain-driven design. Recognizing when a project has actually reached that point, rather than adopting these patterns prematurely "because a blog post recommended it," is itself a judgment call worth getting right; the overhead of these more advanced patterns is rarely justified for a typical business website or even a fairly substantial web application.

A Worked Example: Tracing a Feature Request Through Every MVC Layer

To make the abstraction concrete, walk through what actually happens, layer by layer, when a logged-in user clicks "Add to Favorites" on a product page. The browser sends a POST request to a specific URL. The router matches that URL and HTTP method to a Controller method. The Controller method first confirms the user is authenticated (a concern often handled by middleware before the Controller method even runs), then calls a method on the Favorite Model or repository, passing the user ID and product ID, without itself knowing or caring how favorites are stored in the database. The Model checks its own business rule — perhaps a maximum number of favorites per account — and if the rule passes, performs the actual database insert, then returns a simple success or failure result back to the Controller. The Controller, now holding that result, decides what response to send: for a traditional server-rendered page, it might redirect back to the product page with a flash message; for an API consumed by a mobile app, it would return a JSON response instead. Notice that the View (or JSON response, in the API case) at no point needed to know anything about how the favorite was validated or stored — it received a finished result and rendered it. This is the entire point of the separation: each layer changed independently of the others, and a developer fixing a bug in the maximum-favorites business rule needs to look in exactly one place, the Model, rather than searching through Controller code, View templates, and database queries scattered across the codebase.

Testing Each Layer in Isolation

The entire point of separating concerns is that each layer becomes independently testable. A Model's business logic can be unit-tested with no HTTP request, no database even, if the Model talks to an interface rather than a concrete repository:

public function testOrderTotalIncludesShipping()
{
    $order = new Order(items: [new Item('Widget', 1000)], shippingCost: 500);
    $this->assertEquals(1500, $order->total());
}

A Controller test, in contrast, checks wiring — given this request, was the right Model method called, and did the right View get rendered with the right data? It does not re-test the Model's arithmetic; that is the Model test's job. This division is what keeps test suites fast: business-logic tests run in milliseconds with no I/O, while the handful of true integration tests that exercise a real database run separately and less often.

Where Teams Get MVC Wrong in Practice

The most common real-world failure is not misunderstanding the pattern in theory but eroding it gradually under deadline pressure. A "quick fix" puts a database query directly in a Controller. Another adds a conditional directly in a View template because passing a computed flag from the Controller felt like extra work in the moment. Six months and a dozen similar shortcuts later, the codebase technically uses an MVC framework but has none of MVC's actual benefits — logic is scattered, nothing is independently testable, and onboarding a new developer means reading every file to understand any one feature.

The fix is not a rewrite. It is a standing discipline: when reviewing a pull request, ask "does this Controller method do anything besides receiving input and delegating?" and "does this View do anything besides displaying data it was given?" Catching drift early is far cheaper than untangling it later.

MVC at Different Scales

For a small site with five pages, full MVC ceremony — dedicated Model classes, a routing layer, View templates — can feel like overhead for overhead's sake, and sometimes it is. The pattern earns its cost once a project has more than a handful of pages, more than one developer, or any logic complex enough that "where does this belong" becomes a real question. Most frameworks exist precisely to make that threshold easy to cross when the time comes, by having the structure already in place rather than requiring a mid-project rewrite.

Closing Thought

MVC is not a Laravel feature, a Symfony feature, or a Rails feature — it predates all of them, originating in desktop GUI frameworks decades before web development existed. What modern PHP frameworks add is convention and tooling around the pattern: a router that maps URLs to Controllers, a templating engine for Views, an ORM for Models. Understanding the underlying separation of concerns is what lets you use any of these frameworks well, and recognize when a codebase — framework or not — has quietly stopped following the pattern it claims to use.

One Last Distinction Worth Keeping Straight

MVC is sometimes confused with the broader idea of "separation of concerns," but it is one specific, narrow implementation of that idea — not the only one, and not always the best fit. Other patterns (MVVM in some frontend frameworks, hexagonal/ports-and-adapters architecture in more complex backend systems) solve the same underlying problem of keeping business logic decoupled from presentation and infrastructure, using different boundaries. Knowing MVC well is valuable specifically because most PHP frameworks are built around it, not because it is the universally correct answer to every architectural question.