Laravel MVC — Fat Controller Payment API Timeout

Every Laravel app you've ever used — a blog, an e-commerce store, a SaaS dashboard — is built on a pattern called MVC. It's not a Laravel invention; it's been around since the 1970s. But Laravel takes that pattern and makes it feel so natural that most developers follow it without even realising they're applying a decades-old architectural principle. Understanding it deeply is what separates a developer who 'writes Laravel' from one who 'thinks in Laravel'.

Before MVC, web apps were a nightmare to maintain. PHP files mixed SQL queries, HTML markup, and business logic all in one place. Change the database table? You'd hunt through fifty files. Redesign the frontend? You'd break the data layer. MVC solves this by enforcing a strict separation of concerns — each layer has one job and only one job, which means changes in one layer rarely ripple into the others.

By the end of this article you'll be able to trace exactly how a browser request travels through a Laravel application from route to response, understand why fat controllers are an anti-pattern, know when logic belongs in a Model versus a Controller versus a Service class, and write code that a teammate can pick up and understand without a walkthrough.

What is Laravel MVC Pattern?

MVC (Model-View-Controller) is a software architectural pattern that separates an application into three interconnected components. Laravel embraces this pattern as its default architecture, providing a clear structure: routes map URLs to controller methods, controllers delegate to models (often via Eloquent ORM) for data operations, and return rendered views (Blade templates) as HTTP responses. This separation ensures that changes in one layer (e.g., database schema) do not ripple into the presentation layer without explicit handling.

In a typical Laravel application, a request travels: public/index.php → HTTP Kernel → Router → Middleware → Controller → Model → View → Response. Each component has a single responsibility. The controller is a thin orchestrator; the model encapsulates business logic and data access; the view handles only presentation logic.

Understanding this flow is critical because common production issues — slow pages, untestable code, inconsistent data — often stem from violating this separation.

<?php

namespace Io\Thecodeforge\Http\Controllers;

use Io\Thecodeforge\Models\Post;
use Illuminate\Http\Request;

class PostController extends Controller
{
    public function index()
    {
        $posts = Post::with('author')->latest()->paginate(10);
        return view('posts.index', compact('posts'));
    }
}

The Request Lifecycle in Laravel MVC

Every request hits public/index.php, then the HTTP kernel. The router matches the URL to a route definition and dispatches it to the appropriate Controller method. That method interacts with Models (often via Eloquent) and returns a View with data. This flow is strict — the Controller never echoes HTML, the Model never handles HTTP input, and the View never writes to the database.

Here's a concrete example of a clean Controller that plays by the rules:

```php <?php

namespace Io\Thecodeforge\Http\Controllers;

use Io\Thecodeforge\Models\Order; use Illuminate\Http\Request;

class OrderController extends Controller { public function show(Order $order, Request $request) { // Implicit route model binding — Laravel fetches the Order by ID $items = $order->items()->with('product')->get(); return view('orders.show', compact('order', 'items')); } } ```

Notice the Controller is thin: it only orchestrates. The Model (Order) contains the relationship definition. The View (orders.show) renders the HTML. No SQL, no raw HTML in the Controller.

<?php

namespace Io\Thecodeforge\Http\Controllers;

use Io\Thecodeforge\Models\Order;
use Illuminate\Http\Request;

class OrderController extends Controller
{
    public function show(Order $order, Request $request)
    {
        $items = $order->items()->with('product')->get();
        return view('orders.show', compact('order', 'items'));
    }
}

Controllers: The Orchestrators (Not the Brains)

A Controller's job is to accept an HTTP request, coordinate with Models or Services, and return a response. That's it. Fat controllers with 300 lines of business logic are the #1 maintainability problem in Laravel apps.

Use resource controllers for standard CRUD operations. They enforce a clear pattern: index, create, store, show, edit, update, destroy. Each method should be under 15 lines.

Dependency injection via the constructor or method injection ensures your controller is testable. Never new Service() inside a controller method — let Laravel's service container resolve it.

<?php

namespace Io\Thecodeforge\Http\Controllers;

use Io\Thecodeforge\Services\ProductService;
use Illuminate\Http\Request;

class ProductController extends Controller
{
    public function __construct(
        private ProductService $productService
    ) {}

    public function store(Request $request)
    {
        $validated = $request->validate([
            'name' => 'required|string|max:255',
            'price' => 'required|numeric|min:0',
        ]);

        $product = $this->productService->create($validated);

        return redirect()->route('products.show', $product);
    }
}

<?php

namespace Io\Thecodeforge\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\HasMany;

class Order extends Model
{
    protected $fillable = ['customer_id', 'status'];

    public function items(): HasMany
    {
        return $this->hasMany(OrderItem::class);
    }

    public function scopePaid($query)
    {
        return $query->where('status', 'paid');
    }

    public function getTotalAttribute(): float
    {
        return $this->items->sum(fn ($item) => $item->price * $item->quantity);
    }

    public function sendConfirmation(): void
    {
        // Logic to send email — could delegate to a Notification class
    }
}

@extends('layouts.app')

@section('content')
    <h1>Order #{{ $order->id }}</h1>

    <ul>
        @foreach($items as $item)
            <li>{{ $item->product->name }} x {{ $item->quantity }} — ${{ number_format($item->price, 2) }}</li>
        @endforeach
    </ul>

    <p><strong>Total:</strong> ${{ number_format($order->total, 2) }}</p>
@endsection

<?php

namespace Io\Thecodeforge\Services;

use Io\Thecodeforge\Models\Order;
use Io\Thecodeforge\Models\Product;
use Illuminate\Support\Facades\DB;

class OrderService
{
    public function placeOrder(array $data, int $customerId): Order
    {
        return DB::transaction(function () use ($data, $customerId) {
            $order = Order::create([
                'customer_id' => $customerId,
                'status' => 'pending',
            ]);

            foreach ($data['items'] as $item) {
                $product = Product::findOrFail($item['product_id']);
                $product->decrement('stock', $item['quantity']);

                $order->items()->create([
                    'product_id' => $product->id,
                    'quantity' => $item['quantity'],
                    'price' => $product->price,
                ]);
            }

            // Charge the customer (third-party API call)
            // $this->paymentService->charge($order, $data['payment_token']);

            $order->update(['status' => 'paid']);

            return $order;
        });
    }
}