Forem: Naveen Kola

Simplifying Service Selection in Laravel Using Resolvers

Naveen Kola — Sat, 27 Dec 2025 15:34:13 +0000

In real-world Laravel applications, we often work with multiple service classes that do the same job in different ways.
For example, multiple payment gateways, external API providers, or notification services.

A common challenge is deciding which service to use at runtime without filling our code with if-else or switch statements.

In this blog, I’ll explain how to use a Resolver pattern in Laravel to solve this problem in a clean and scalable way with a real-world example.

The Problem: Too Many if-else Conditions
Let’s say we support multiple payment gateways in our application: Stripe and PayPal.

A common approach looks like this:

if ($paymentType === 'stripe') {
    $service = new StripePaymentService();
} elseif ($paymentType === 'paypal') {
    $service = new PaypalPaymentService();
} else {
    throw new Exception('Invalid payment type');
}

$service->charge($data);

What’s wrong with this approach?

Business logic is tightly coupled
Adding a new payment gateway means modifying existing code
Hard to test and maintain
Violates the Open/Closed Principle

This code works, but it doesn’t scale well.

What Is a Resolver?

A Resolver is a class responsible for deciding which service implementation should be used based on runtime data.

In simple terms:

A resolver returns the correct service class for you, so your business logic stays clean.

Real-World Example: Payment Service Resolver

Let’s refactor the above example using a Resolver pattern.

Step 1: Create a Common Interface
All payment services should follow the same contract.

interface PaymentServiceInterface
{
    public function charge(array $data): bool;
}

Step 2: Create Service Implementations

Stripe Service

class StripePaymentService implements PaymentServiceInterface
{
    public function charge(array $data): bool
    {
        // Stripe payment logic
        return true;
    }
}

PayPal Service

class PaypalPaymentService implements PaymentServiceInterface
{
    public function charge(array $data): bool
    {
        // PayPal payment logic
        return true;
    }
}

Each service handles its own logic, but they all follow the same interface.

Step 3: Create the Resolver Class

class PaymentServiceResolver
{
    public function __construct(
        public readonly StripePaymentService $stripePaymentService,
        public readonly PaypalPaymentService $paypalPaymentService
    ) {}

    public function resolve(string $type): PaymentServiceInterface
    {
        return match ($type) {
            'stripe' => $this->stripePaymentService,
            'paypal' => $this->paypalPaymentService,
            default => throw new InvalidArgumentException('Unsupported payment type'),
        };
    }
}

Why use constructor injection?

Makes dependencies explicit and easier to understand
Improves unit testability (easy to mock services)
Keeps the resolver clean and focused
Fully leverages Laravel’s dependency injection container

💡 Note :
You could also resolve services using app() inside the resolver, but constructor injection is generally preferred for cleaner architecture and better testing.

Step 4: Use the Resolver in Your Business Logic

class PaymentController extends Controller
{
    public function store(
        Request $request,
        PaymentServiceResolver $resolver
    ) {
        $paymentType = $request->get('payment_type');

        $service = $resolver->resolve($paymentType);
        $service->charge($request->all());

        return response()->json([
            'message' => 'Payment processed successfully'
        ]);
    }
}

✨ Clean, readable, and easy to extend.

Adding a New Service Is Easy

Want to add Razorpay later?

Create RazorpayPaymentService
Implement PaymentServiceInterface
Update resolver

'razorpay' => $this->razorpayPaymentService,

No changes needed in controllers or business logic.

Benefits of Using Resolvers

✅ Cleaner and readable code

✅ Easy to add new services

✅ Follows SOLID principles

✅ Centralized service selection logic

✅ Easy to unit test

Bonus: Making the Resolver More Flexible

Instead of hardcoding values, you can move mapping to a config file:

// config/payment.php
return [
    'stripe' => StripePaymentService::class,
    'paypal' => PaypalPaymentService::class,
];

Resolver

class PaymentServiceResolver
{
    public function resolve(string $type): PaymentServiceInterface
    {
        $service = config("payment.$type");

        if (! $service) {
            throw new InvalidArgumentException('Unsupported payment type');
        }

        return app($service);
    }
}

This makes your system even more configurable.

Final Thoughts

Resolvers are a simple yet powerful pattern for managing multiple service implementations in Laravel.

They help you:

Avoid messy conditionals
Keep business logic clean
Build systems that scale gracefully

If you work with multiple APIs, payment gateways, or providers, Resolvers can significantly improve your code quality.

🚀 Level Up Your Laravel Requests with DTOs (Data Transfer Objects)

Naveen Kola — Mon, 01 Sep 2025 15:56:15 +0000

When building Laravel applications, we often rely on Form Requests for validation. They’re great for keeping controllers clean and ensuring input data is valid before reaching business logic.

But here’s the problem:
After validation, many developers still use raw arrays or the request object itself to pass data deeper into their application services, repositories, or jobs. This can lead to messy, fragile code that’s hard to maintain.

This is where DTOs (Data Transfer Objects) come in. A DTO acts as a simple, structured object to carry data safely and clearly through your application.

Let’s see how we can use DTOs inside Laravel Form Requests.

🛠 User Registration Flow

Imagine you’re building a user registration feature. Your form collects these inputs:

name
email
password

Step 1: Create a Form Request

<?php

declare(strict_types=1);

namespace App\Http\Requests\Auth;

use App\Http\Requests\Auth\Data\RegisterUserData;
use Illuminate\Foundation\Http\FormRequest;

class RegisterUserRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'email', 'unique:users,email'],
            'password' => ['required', 'string', 'min:8'],
        ];
    }

    public function dto(): RegisterUserData
    {
        return new RegisterUserData(
            $this->input('name'),
            $this->input('email'),
            $this->input('password'),
        );
    }
}

Here, we’ve added a dto() method to return a structured object instead of raw inputs.

Step 2: Define the DTO

<?php

declare(strict_types=1);

namespace App\Http\Requests\Auth\Data;

class RegisterUserData
{
    public function __construct(
        public readonly string $name,
        public readonly string $email,
        public readonly string $password,
    ) {}
}

This class represents the validated, immutable registration data.

Step 3: Use the DTO in Your Controller

<?php

declare(strict_types=1);

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use App\Http\Requests\Auth\RegisterUserRequest;
use App\Services\Auth\RegisterUserService;

class RegisterController extends Controller
{
    public function __construct(
        private RegisterUserService $registerUserService
    ) {}

    public function store(RegisterUserRequest $request)
    {
        $userData = $request->dto();

        $user = $this->registerUserService->register($userData);

        return response()->json([
            'message' => 'User registered successfully!',
            'user' => $user,
        ]);
    }
}

Now your controller isn’t dealing with arrays or $request->input(). Instead, it passes a clean RegisterUserData DTO to the service.

Step 4: Service Layer Uses the DTO

<?php

declare(strict_types=1);

namespace App\Services\Auth;

use App\Http\Requests\Auth\Data\RegisterUserData;
use App\Models\User;
use Illuminate\Support\Facades\Hash;

class RegisterUserService
{
    public function register(RegisterUserData $data): User
    {
        return User::create([
            'name' => $data->name,
            'email' => $data->email,
            'password' => Hash::make($data->password),
        ]);
    }
}

The service doesn’t care about request objects. It only knows it needs a RegisterUserData object. This makes it reusable in CLI commands, jobs, or tests.

💡 Another Example: Payment Checkout

Consider a checkout request with fields like:

amount
currency
payment_method

Instead of juggling arrays like $request->only(['amount', 'currency', 'payment_method']), you can use a DTO:

$checkoutData = $request->dto();

$this->paymentService->process($checkoutData);

This makes your code much clearer and type-safe.

✅ Benefits of Using DTOs in Form Requests

Clarity: $request->dto() is cleaner than $request->only(['field1', 'field2']).
Type Safety: IDE autocompletion + compile-time checks help prevent mistakes.
Immutability: DTOs don’t change once created.
Separation of Concerns: Controllers handle requests, services handle logic, DTOs handle data.

🚀 Conclusion

DTOs may seem like a small addition, but they can greatly improve the maintainability and readability of your Laravel projects.

Next time you create a Form Request, don’t just validate inputs, wrap them into a DTO. Your future self (and your teammates) will thank you!

Simplifying Data Access in Laravel with the Repository Pattern

Naveen Kola — Thu, 11 Jul 2024 08:52:57 +0000

In software development, maintaining clean and manageable code is essential. One way to achieve this in Laravel is by using the Repository Pattern. This pattern allows you to separate the data access logic from the business logic, making your code more modular, testable, and maintainable. In this blog post, we’ll explore the Repository Pattern in Laravel and provide an implementation example.

What is the Repository Pattern?

The Repository Pattern is a design pattern that mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. It encapsulates the logic for accessing data sources, such as databases, and provides a clean API for interacting with data.

Benefits of Using the Repository Pattern

Separation of Concerns: Keeps your controllers and services clean by separating data access logic.
Easier Testing: Facilitates unit testing by allowing you to mock the repository.
Code Reusability: Promotes code reuse by centralizing data access logic in repositories.

Understanding Code Structure Without the Repository Pattern

Before diving into the implementation of the Repository Pattern, let’s look at what code structure might look like without it. Here’s an example of how a typical controller might handle data access directly:

Controller Without Repository Pattern

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Models\YourModel;

class YourModelController extends Controller
{
    public function index()
    {
        $models = YourModel::all();

        return response()->json($models);
    }

    public function store(Request $request)
    {
        $model = YourModel::create($request->all());

        return response()->json($model, 201);
    }

    public function show(int $id)
    {
        $model = YourModel::findOrFail($id);

        return response()->json($model);
    }

    public function update(Request $request, int $id)
    {
        $model = YourModel::findOrFail($id);
        $model->update($request->all());

        return response()->json($model);
    }

    public function destroy(int $id)
    {
        $model = YourModel::findOrFail($id);
        $model->delete();

        return response()->json(null, 204);
    }
}

Problems with This Approach

Tightly Coupled Code: The data access logic is tightly coupled with the controller, making it difficult to manage and test.
Code Duplication: Similar data access logic might be duplicated across multiple controllers.
Harder to Maintain: Any change in the data access logic requires changes in multiple places.
Difficult Testing: Testing controllers requires setting up the database, making unit tests slower and harder to isolate.

Implementing the Repository Pattern in Laravel
To address these issues, we can use the Repository Pattern. Let’s dive into the implementation of the Repository Pattern in Laravel.

Step 1: Define the Repository Interface
First, we’ll define an interface for our repository. This interface outlines the methods that our repository will implement.

<?php

namespace App\Repository;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Collection;

interface EloquentRepositoryInterface
{
    public function save(array $attributes): Model;
    public function update(Model $model, array $attributes): Model;
    public function delete(Model $model): void;
    public function byId(int $id): ?Model;
    public function byQuery(Builder $query): ?Model;
}

Step 2: Implement the Repository
Next, we’ll implement the repository interface. This implementation will handle the data access logic.

<?php

namespace App\Repository;

use App\Exceptions\Repository\InvalidModelHttpException;
use App\Exceptions\Repository\UnableToDeleteHttpException;
use App\Exceptions\Repository\UnableToSaveHttpException;
use App\Exceptions\Repository\UnableToUpdateHttpException;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Support\Collection;
use Psr\Log\LoggerInterface;
use Throwable;

abstract class EloquentRepository implements EloquentRepositoryInterface
{
    public function __construct(
        private readonly Model $modelClass,
        private readonly LoggerInterface $logger
    ) {}

    public function save(array $attributes): Model
    {
        try {
            $model = $this->modelClass->newInstance($attributes);
            $model->saveOrFail();

            return $model;
        } catch (Throwable $e) {
            $this->logger->alert(
                'Unable to save model',
                [
                    'errorMessage' => $e,
                    'method' => __METHOD__,
                    'modelClassName' => $this->modelClass::class
                ]
            );

            throw new UnableToSaveHttpException();
        }
    }

    public function update(Model $model, array $attributes): Model
    {
        if ($model::class !== $this->modelClass::class) {
            throw new InvalidModelHttpException();
        }

        try {
            $model->updateOrFail($attributes);
            return $model;
        } catch (Throwable $e) {
            $this->logger->alert(
                'Unable to update model',
                [
                    'errorMessage' => $e,
                    'method' => __METHOD__,
                    'modelClassName' => $this->modelClass::class
                ]
            );

            throw new UnableToUpdateHttpException();
        }
    }

    public function delete(Model $model): void
    {
        if ($model::class !== $this->modelClass::class) {
            throw new InvalidModelHttpException();
        }

        try {
            $model->deleteOrFail();
        } catch (Throwable $e) {
            $this->logger->alert(
                'Unable to delete model',
                [
                    'errorMessage' => $e,
                    'method' => __METHOD__,
                    'modelClassName' => $this->modelClass::class
                ]
            );

            throw new UnableToDeleteHttpException();
        }
    }

    public function byId(int $id): ?Model
    {
        return $this->modelClass->newQuery()->find($id);
    }

    public function byQuery(Builder $query): ?Model
    {
        return $this->modelClass->newQuery()
                  ->setQuery($query->getQuery())->first();
    }
}

Handling Custom Exceptions
To handle errors gracefully, we’ll define custom exceptions for common error scenarios in our repository.

Step 3: Define Custom Exceptions
Let’s define custom exceptions for handling invalid models and data access failures.

<?php

namespace App\Exceptions\Repository;

use App\Exceptions\HttpException;
use Symfony\Component\HttpFoundation\Response;

class InvalidModelHttpException extends HttpException
{
    protected $code = Response::HTTP_INTERNAL_SERVER_ERROR;
    protected $message = 'Internal server error';
}

class UnableToSaveHttpException extends HttpException
{
    protected $code = Response::HTTP_INTERNAL_SERVER_ERROR;
    protected $message = 'Unable to save the model';
}

class UnableToUpdateHttpException extends HttpException
{
    protected $code = Response::HTTP_INTERNAL_SERVER_ERROR;
    protected $message = 'Unable to update the model';
}

class UnableToDeleteHttpException extends HttpException
{
    protected $code = Response::HTTP_INTERNAL_SERVER_ERROR;
    protected $message = 'Unable to delete the model';
}

Using the Repository in Controllers
Now that we have our repository implemented, let’s see how we can use it in controllers.

Step 4: Injecting the Repository into a Controller
In your controller, you can inject the repository via the constructor and use it to handle data access logic.

<?php

namespace App\Http\Controllers;

use App\Repository\EloquentRepositoryInterface;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use App\Models\YourModel;

class YourModelController extends Controller
{
    public function __construct(
        private EloquentRepositoryInterface $repository
    )
    {}

    public function index(): JsonResponse
    {
        $models = $this->repository->listByQuery(YourModel::query());

        return response()->json($models);
    }

    public function store(Request $request): JsonResponse
    {
        $model = $this->repository->save($request->all());

        return response()->json($model, 201);
    }

    public function show(int $id): JsonResponse
    {
        $model = $this->repository->byId($id);

        return response()->json($model);
    }

    public function update(Request $request, int $id): JsonResponse
    {
        $model = $this->repository->byId($id);
        $updatedModel = $this->repository->update($model, $request->all());

        return response()->json($updatedModel);
    }

    public function destroy(int $id): JsonResponse
    {
        $model = $this->repository->byId($id);
        $this->repository->delete($model);

        return response()->json(null, 204);
    }
}

Conclusion
Using the Repository Pattern in Laravel can greatly enhance the maintainability and testability of your application. By abstracting the data access logic into repositories, you can keep your codebase clean and modular. You can then inject these repositories into your controllers and services to handle data operations, making your application more robust and easier to manage.

Give it a try in your next Laravel project and experience the benefits firsthand!