Laravel: From Controller to Action - Pass Array or Data Object?

Example based on a tweet by Nuno Maduro, discussing the array strictness for static analysis and Spatie Laravel Data package in action.

Links mentioned in the video:

- - - - -
Support the channel by checking out my products:

- - - - -
Other places to follow:

[davelemmens]

I like to create an interface for the data I need in an action class. That interface has the getters defined, like getName() and getDescription(). In my action class, I program against that interface. Than, I let my form request implement that interface. It's very simple to add a few getters to that class to return the form data.

This way, everything is typed, and I can just pass along my form request to the action, without the action knowing it is actually a request class. No external packages needed, and it's clean code. This is sufficient for 95% of all use cases for me. If I do need to call the action from somewhere else, I can just create a DTO that implements the same interface and use that DTO in my commands for instance.

[elsartesano]

In my opinion, adding these kind of packages is a bit of an overkill when there is something similar out of the box. Of course, it depends on the needs of the application, but I tend to write my own DTOs extending from the Fluent class that lives in the Support domain of Laravel. It's not as complete as this library, but allows me to avoid extra packages, especially when the DTOs are not very complex. But of course, this is only my approach, not a silver bullet for every software.

What I tend to do is to add a method in my Form Request classes that will format the data and return this DTO with the needed values (something like " public function toDto(): MyDto; "). This approach works well for me

[francescoleto]

I used to create dto to prevent future changes. Maybe at the start of a project an array could be composed by two keys, but what if I need to push more keys?

[VKLuc]

If the logic within the called service is subject to future changes, using dto's can be beneficial. It becomes possible to add a new dto to trigger new/old implementations. When the logic has low probability of change, using dto's is probably an overkill (gold plating)

[irlvnqi]

IMO, I would've preferred if this Spatie package write phpdoc-annotated array structure that can withstand PHPStan level max analysis instead of generating DTOs.

[_plamp_]

What is the benefit of using this pattern vs having these operations at the Model level?

[florianlutze]

I don't quite understand what's the reason to use the laravel-data objects then instead of passing the form request to the service/action?
In the end they both do the same thing now? Both validate and store the structure of the data. But having a clean data object in the service/logic layer is probably the cleaner way to go instead of passing formrequests

[SXsoft]

I prefer to use request validation classes just because you can build deep nested validation fields like 5levels deep for json or depending on other fields, and keep the dot just as a data mapping
But it's not just about personal preference, you might be working in a project with different people and you want to have a single specific style of coding since every dev has different levels of experience

[chibuikeumezinwa]

I've not seen a genuine reason to install a package for data validation and transfer when you can do just that with laravels form validation class. I've always seen that as an overkill.

[DoonSafari]

Hi why you are not uploading content in your python daily channel