Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

codedoktor's avatar

Passing request parameters to methods

Generally speaking, do you usually pass all request parameters to methods or just the ones required?

Example: In my UserController i have:

public function store(StoreUserRequest $request, StoreUser $action): RedirectResponse
{
    $action->handle($request->validated());

    return redirect(route('dashboard', absolute: false));
}

The action called looks like this:

public function handle(array $attributes): void
{
    // Store the new user
    $user = User::create([
        'first_name' => $attributes['first_name'],
        'last_name' => $attributes['last_name'],
        'email' => $attributes['email'],
        'password' => Hash::make($attributes['password'])
    ]);

    // Fire event to send verification mail
    event(new Registered($user));

    // Login the user
    Auth::login($user);
}

So i basically pass all attributes of the request eventhough that might be to much.

This makes it a bit more flexible when adding attributes to the user model (which isn't that rare), but on the other hand, it adds some overhead and doesn't feel strict enough. Additionally, one could argue that it doesn't adhere to the Single Responsibility Principle (SRP) as it is now the actions job to handle the "not required" attributes.

What do you all think about it?

0 likes
8 replies
jj15's avatar
jj15
1 year ago
Best Answer
Level 10

My preference (and what I usually believe to be the better option) is to explicitly define each parameter needed. It makes things clearer from both sides and you have the added strictness of types as you mentioned.

If your method requires a lot of parameters to function, you may want to extract them into a separate object that you can pass around. This is typically known as a DTO or "Data Transfer Object" and is a good alternative to an array. Spatie has a very helpful and feature-packed package for this.

1 like
codedoktor's avatar

@jj15 Thanks for your reply!

I also prefer passing only the required parameters. I have to admit that I have never worked with DTOs before. Now that you’ve mentioned them, I took a look and found them to be a great solution for data transfer—thanks for that!

However, after reviewing the Spatie package, I will probably decide against using it and instead implement DTOs manually. The reason is that, despite being feature-rich, the package does not adhere to the Single Responsibility Principle (SRP). This is because its main selling point is combining different layers.

I also try to work "as close to Laravel as possible" For me, this means maintaining Laravel's structure rather than modifying it, ensuring that new employees can quickly get up to speed with the codebase. Since the package essentially replaces form requests and resources, I’d rather avoid that approach.

Of course, this is entirely subjective, and I’d love to hear your thoughts on it!

Tray2's avatar

@codedoktor I would probably remove the handle method, and inline the function in my store method instead.

public function store(StoreUserRequest $request): RedirectResponse
{
    $user = User::create($request->validated());
	
	event(new Registered($user);
	
	Auth::login($user);

    return redirect(route('dashboard', absolute: false));
}

I don't see the need to extract it more than that in this case, however you can always put the action in the model.

User::createNewUser($request->validated());

static function createNewUser($validatedUser)
{
    $user = User::create($validatedUser));
	
	event(new Registered($user);
	
	Auth::login($user);
}
1 like
jj15's avatar

@codedoktor

You're welcome. A manually-defined DTO is just fine and what I do when I need one, but some prefer using a package like the one from Spatie. It really just boils down to personal preference at the end of the day and knowing what options you have available and when to use them.

1 like
codedoktor's avatar

@Tray2 I am refactoring my application to actions, which is why I have a StoreUser class to "handle" persisting a new user. I know it might seem cumbersome for the little code there is right now, but this was just intended as an example.

reaz's avatar

Not sure why you think its not strict enough. The validation rules should take care of extra data not passing through from request. you can make you validation class as strict as you want.

jj15's avatar

@reaz

It looks like the OP is using an action class to abstract the logic away from the controller, making it a separate, isolated unit. This makes the logic reusable if needed, such as from a console command instead of an HTTP request.

I believe their concern about extra data coming through was rooted more in terms of having the action only knowing what it needs to know in order to perform its task.

Request validation is important, but having basic type safety at the language level is also good. Passing an array that could contain anything makes this harder.

codedoktor's avatar

@reaz What I mean is not the strictness of the validation but the strictness of which data is allowed to be passed to the action (in this case StoreUser). It's either passing a bag of attributes and checking whats inside it within the action or defining which attributes should be passed to the action inside the method calling the action. It is not really about validation at all

Please or to participate in this conversation.