Laravel MVC — Fat Controller Payment API Timeout

If you find yourself writing a controller method that does more than three things (validate input, call a service/model, return a view), break it down.

<?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);
    }
}

Models: Where the Business Logic Lives

Models are not just database representations. They are the core of your domain logic. Eloquent models can hold relationships, scopes, accessors, mutators, and custom query methods. This is where you define how your data behaves.

For example, an Order model can have a total accessor that sums its items. A paid scope that filters unpaid orders. A sendConfirmation method that triggers a notification. All of this belongs in the model, not the controller.

Use Eloquent's relationship methods (hasMany, belongsTo, morphMany) to define how models connect. Then leverage eager loading (with()) to avoid the N+1 problem.

Validation rules that are tied to the model's state belong in store or update methods in a Form Request, but computed properties belong in the model.

<?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
    }
}

Views: Blade Templates, Layouts, and Components

Blade is Laravel's powerful templating engine. It extends PHP with control structures, layouts, components, and partials. Views should only contain presentation logic — loops, if/else, formatting — never raw SQL queries or complex business math.

Use layouts for common page structure. Define sections with @yield or use Blade components for reusable UI pieces. Components can accept data and have their own logic encapsulated in a component class.

Always pass data from the controller to the view using compact() or with(). Avoid using the View::share() globally except for shared navigation data.

Avoid writing complex PHP in Blade. If you need a helper, create a Blade directive or a dedicated view composer.

@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

Advanced MVC: Service Layer and Repositories

When controllers get too heavy or models start to hold business logic that spans multiple models, introduce a service layer. Services are plain PHP classes (often without extending Eloquent) that encapsulate complex operations.

For example, an OrderService can handle placeOrder() which creates the order, deducts inventory, charges the customer, and sends confirmation. The controller calls $orderService->placeOrder($request).

Repositories are an additional abstraction if you need to switch between databases or mock the data layer in tests. In most Laravel apps, Eloquent is sufficient, so repositories can add unnecessary complexity. Use them only when you have a clear reason (multiple data sources, heavy caching logic).

<?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;
        });
    }
}

Why MVC? The Real Reason We Separate Concerns

You don't use MVC because the manual says so. You use it because without it, your routes/web.php becomes a 2,000-line graveyard of Closure-based logic that nobody touches without breaking three other features. MVC forces a contract: routes dispatch, controllers orchestrate, models own business rules, views present. That contract makes your code predictable when a hotfix lands at 2 AM.

Consider what happens without MVC: raw SQL in Blade templates, form validation in routes, queries scattered across controllers. Two months later, you can't tell if User::where('active', 1) belongs to billing or notifications. MVC prevents that chaos by enforcing a single source of truth for each concern.

The payoff? Onboarding new devs takes days, not weeks. Refactoring legacy features becomes surgical, not exploratory. And when production breaks, you grep a specific directory instead of the entire codebase.

// io.thecodeforge
// Without MVC — logic leaks everywhere
Route::get('/dashboard', function () {
    $users = DB::table('users')->where('active', 1)->get();
    $html = '<ul>';
    foreach ($users as $user) {
        $html .= '<li>' . $user->name . '</li>';
    }
    return $html . '</ul>';
});

// With MVC — predictable, testable
class DashboardController
{
    public function __invoke(): View
    {
        $activeUsers = User::query()->whereActive(true)->get();
        return view('dashboard', compact('activeUsers'));
    }
}

Advantages of Using MVC: What Breaks if You Skip It

MVC isn't abstract theory. It's a survival mechanism for applications that live longer than one sprint. Three concrete advantages: testability, parallel development, and caching granularity.

Testability: Controllers handle HTTP concerns; models handle logic. When you phpunit a model, you're not mocking request objects or session data. That means your test suite runs in seconds, not minutes. Without MVC, every test is a fragile integration test that breaks when someone renames a Blade partial.

Parallel development: With MVC, a frontend dev can craft Blade components while a backend dev optimizes a repository query. The interface is the method signature, not dump() debugging in a view. You don't wait for the database to be seeded to see UI changes — you hardcode a ViewModel.

Caching granularity: Because views are isolated, you can cache rendered fragments. Because models are isolated, you can cache query results. Without separation, you cache the entire response or nothing. That's binary thinking, and it kills performance at scale.

// io.thecodeforge
// Model method — cache-safe, reusable
class User extends Authenticatable
{
    public function activeCount(): int
    {
        return Cache::remember('users.active.count', 3600, function () {
            return $this->whereActive(true)->count();
        });
    }
}

// Controller — only concerns itself with HTTP
class UserStatsController
{
    public function index(User $user): View
    {
        return view('stats', [
            'activeCount' => $user->activeCount(),
        ]);
    }
}

Features of Laravel That Make MVC Actually Work in Production

Laravel's features aren't marketing fluff. They're the reason MVC patterns survive real-world pressure. Four features matter most:

Eloquent ORM: The model layer in MVC lives or dies by its data layer. Eloquent gives you eager loading, global scopes, and accessors — all without raw SQL. When a junior writes $order->items->sum('price'), they're using MVC correctly without knowing it. The model encapsulates the relationship, not the controller.

Blade Components: Views aren't just HTML dumps. Blade components give you reusable UI with scoped logic. Think @alert('warning') instead of manually constructing a danger div in every view. Components enforce the view's single responsibility: presentation, not computation.

Artisan Commands: MVC requires discipline. Artisan generates boilerplate — php artisan make:model -mf creates model, migration, and factory in one command. That speed removes the friction argument people use to skip MVC.

Form Requests: Validation leaking into controllers ruins MVC. Form Requests keep validation in the HTTP layer where it belongs. Your controller stays clean; your validation logic is reusable between endpoints.

// io.thecodeforge
// Form Request — validation stays in HTTP layer
class StoreUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email' => ['required', 'email', 'unique:users,email'],
            'role' => ['required', 'in:admin,editor'],
        ];
    }
}

// Controller — no validation clutter
class UserController
{
    public function store(StoreUserRequest $request)
    {
        User::create($request->validated());
        return redirect()->route('users.index');
    }
}