Laravel app/Action Classes: Example of "Heavy" Usage
HTML-код
- Опубликовано: 5 сен 2023
- Actions in Laravel got really popular, let's take a look at an open-source example.
My course "How to Structure Laravel Projects" laraveldaily.com/course/struc...
- - - - -
Support the channel by checking out my products:
- My Laravel courses: laraveldaily.com/courses
- Laravel QuickAdminPanel: quickadminpanel.com
- Livewire Kit Components: livewirekit.com
- - - - -
Other places to follow:
- My weekly Laravel newsletter: us11.campaign-archive.com/hom...
- My personal Twitter: / povilaskorop Хобби
Personally speaking I would do the validation in the Form Request which will be called in the controller.
Once the inputs are validated only then pass those to Actions.
I will do the same to make sure everything is clean before to send anything to Actions, and keep those validations rules into Http\Requests
Bitte then, it is possible to use Actions without validation.
I'm doing the same. However, there is a tradeoff. Keep in mind that the whole point of action is to be self-contained.
Let's say a new dev comes in. There's nothing that's stopping him from calling the action with invalid or raw input.
@@digvijayadthere's nothing to stop new devs from performing model CRUD operations directly either or dropping a raw DB query in there. Discipline is always required.
Great content, I became a big fan 👏
I'm a big fan of FromRequest, so i would have put this logic in, maybe with Observer to handle logic synced with the model related action, because you clean the controller but the action is very dirty
A course of general security approaches would be good...
There's this video covering most common things: ruclips.net/video/dWVTfY6cMBs/видео.htmlsi=F-xUxsRXeb8X7Agh
More of a structured approach rather than ServerService::class, though validation could still be done in the Controller class
There are very many ways to skin the same cat 😉 Whether it's Actions, Factories, Sevices, Projectors, Repositories etc or, usually, some mix of the above.
The important thing to remember is moderation, it's easy to be enticed by a new pattern that will provide lots of future proofing and extensibility etc, but it can be a waste of development time if you never end up using it. This is especially true with microservices. I've seen many microservices that only do 1 thing (and will only ever need to) but because the devs have invested in fancy patterns, they end up spreading out simple logic across a ton of files for no real gain.
In the words of the wise, keep it simple stupid (but no simpler)
That's not to say these patterns aren't still useful, they definitely are!
Just don't overdo it 😉
I remember seeing an ISPs newly rewritten ordering API recently. The old version worked fine and consisted of about 400 lines of Perl 5 code, the new Devs chose to rewrite it in a JS framework, same functionality, but now spread over dozens of files with hundreds of dependencies. Granted it probably is more flexible, but the company has no plans to build on the API anytime soon...
Very much like controllers actually. Each controller run one process.
IMHO, and I'm not saying that is perfect or the only one approach, I use:
- repositories: to manager data.
- services: to perform actions AND return something.
- actions: to perform action.
And what controllers do in your design?
@@al.e.k Controllers check data (with Form Requests) and pass them to repositories, etc. so they are like connections.
@@IlPandax
So, as I see:
1. your actions contain domain logic, hence models are anemic
2. services keep it's own logic whickh orchestrates actions
3. controllers make validations and call services
Isn't it?
@@al.e.k Pretty much, even though I don't fully understand the concept of "anemic model" (sorry english is not my main language)...I think you meant "without unrelated code", didn't you?
@@al.e.k Sorry just one thing: Controllers make validation and can call repositories to manage records in the DB. If there are actions to be performed, a repository can call a service (if it needs a return value) or an action (if it's just code to be executed). I hope I explaned myself. ;)
EDIT: of course there are also events/listeners, usually, that take place of multiple actions. And also Jobs if I want to use queues. XD
Struts days.
Hallo sir, im one of your LTD member of laravel daily. Can o request LMS tutorial?
It depends on how you define that LMS: it can be very simple or very complex. Send me the details povilas@laraveldaily.com and I will evaluate if it's worth me spending a few weeks on such tutorial.
Please what’s the name of the github repository ?
vitodeploy/vito on github
@@LaravelDaily thanks
This looks a lot like services
How is nobody speaking about Factories for creating object/entities with such complicated process of creation/validation? This would be the perfect example for factory, imho
Factories can be used in conjunction with actions 😁
Some use actions almost like Event Sourcing event projections. So an actions to named "CreateUser" could be invoked from the controller, the action itself would then invoke the UserFactory to create the user record. The benefit of this is that one could record all actions, almost like an audit trail.
What are the benefits of actions over event sourcing? I don't know yet 😂
To me, the validation logic should be elsewhere...
I don't like this structure.
Validation logic in sprated action.
If you want to sparate Validation move it to requests .
Please talk about beyondcode/laravel-websockets and how you got it working on VPS hosting
I don't use that package, I use soketi instead, see our tutorial: laraveldaily.com/post/websockets-laravel-soketi-real-time-updates-example