Great video! I've been using the actions pattern for a datasharing implementation in my food ordering app - something along the lines of: $dataShareAction = new DataShareAction($apiClient, $transformer); $dataShareAction($order); Where $apiClient and $transformer are specific to the third party receiving the data. Works great and is super easy to reuse.
When the actions pattern goes wrong everything sucks. My current employer transitioned from outsourced developers to in-house developers, and I was hired as a part of that transition. The outsourced team used "actions" by name, but not in the way you described. Their actions aren't injected, aren't mock-able (they use a static execute method, meaning it can't be mocked), they tend to be littered with side effects, and there's instances where one action calls another action which calls a third action and so on. All of this has lead to spaghetti code that is nearly impossible to unit test, and incredibly difficult to follow.
Reminds me of commands and queries to be honest. You could encapsulate the „PublishBook“ action logic in a command and I guess it would only be a matter of naming, correct?
Its almost that, but its more in line with what a application service should be, CQRS has a more specific meaning to write persistance logic, its more like take your repository, and extract each method into a class.
Mailing an email would be a side effect, so it wouldn't be as strict as functional programming, but I get the picture. It helps with code organization and removes possible spaghetti code inside the entry point (controller, command, etc).
Is this pattern somehow different from Clean Architecture? Uncle Bob has a great video about it named "The Principles of Clean Architecture by Uncle Bob Martin" But mainly there's (Bob calls it 'Interactor', we're calling it an 'UseCase' or 'Feature') class which encapsulate one use-case (or logic like "ListUsersUseCase", "ApproveUserUseCase", "PublishBookUseCase") which should be independent from infrastructure. And then use cases it self must not know from where the data came from.
Yes, this is a fantastic pattern. Your book Laravel beyond CRUD was a game changer for me. I am so greatful! I use execute as the action method. That reads good in the code where you use it I think.
Dude read about the simplicity and reliability of functional programming where a function takes an input and returns an output, wrapped it up in classes because after all that's what people in the OOP world do and called it his pattern. What an ego!
Yes 😅 keeping business logic in one place and call that new invented pattern...what is the diff between action pattern and use case or service repo pattern? Basically the same, he just calls it action pattern
lol ok I mean yeah sure, literally services but you separate your WhateverService into invocable little services called action. why I watch shit like that at night instead of sleeping
Do you use the action pattern? Share your experience with it in the comments!
Hi, can you explain more about "virtual properties" in PHP 8.4??
You “invented” actions like I invented the wheel lol.
CQRS, but simplified
Huh. My co-workers and I were writing actions in this way in 2012. But I must be wrong, because you invented this in 2018.
Great video! I've been using the actions pattern for a datasharing implementation in my food ordering app - something along the lines of:
$dataShareAction = new DataShareAction($apiClient, $transformer);
$dataShareAction($order);
Where $apiClient and $transformer are specific to the third party receiving the data. Works great and is super easy to reuse.
but actions were invested by Kent Back.... in 90s
So, how is this different from the “Command” pattern?
en.m.wikipedia.org/wiki/Command_pattern
When the actions pattern goes wrong everything sucks. My current employer transitioned from outsourced developers to in-house developers, and I was hired as a part of that transition. The outsourced team used "actions" by name, but not in the way you described. Their actions aren't injected, aren't mock-able (they use a static execute method, meaning it can't be mocked), they tend to be littered with side effects, and there's instances where one action calls another action which calls a third action and so on. All of this has lead to spaghetti code that is nearly impossible to unit test, and incredibly difficult to follow.
Reminds me of commands and queries to be honest. You could encapsulate the „PublishBook“ action logic in a command and I guess it would only be a matter of naming, correct?
Its almost that, but its more in line with what a application service should be, CQRS has a more specific meaning to write persistance logic, its more like take your repository, and extract each method into a class.
Mailing an email would be a side effect, so it wouldn't be as strict as functional programming, but I get the picture.
It helps with code organization and removes possible spaghetti code inside the entry point (controller, command, etc).
Is this pattern somehow different from Clean Architecture? Uncle Bob has a great video about it named "The Principles of Clean Architecture by Uncle Bob Martin"
But mainly there's (Bob calls it 'Interactor', we're calling it an 'UseCase' or 'Feature') class which encapsulate one use-case (or logic like "ListUsersUseCase", "ApproveUserUseCase", "PublishBookUseCase") which should be independent from infrastructure. And then use cases it self must not know from where the data came from.
Thoughts about a service class calling all of these independent-but-related actions like an orchestrator?
Thanks Brendt!
Yes, this is a fantastic pattern. Your book Laravel beyond CRUD was a game changer for me. I am so greatful!
I use execute as the action method. That reads good in the code where you use it I think.
So using action pattern for controller logic to keep the controllers short ?
Don't see much difference between actions and jobs. But my struggle with Action is keep then side effect free.
thanks for subtitle exists
Dude read about the simplicity and reliability of functional programming where a function takes an input and returns an output, wrapped it up in classes because after all that's what people in the OOP world do and called it his pattern. What an ego!
Yes 😅 keeping business logic in one place and call that new invented pattern...what is the diff between action pattern and use case or service repo pattern? Basically the same, he just calls it action pattern
You seem nice. 💩🤡
lol ok I mean yeah sure, literally services but you separate your WhateverService into invocable little services called action. why I watch shit like that at night instead of sleeping
Thank fun!
Huge ego. Little to no contribution. Study harder. Git gud
Who hurt you bro?
Transaction Script
use case 🥱
Exactly, can be called from a query or command bus, He says similar but at the end is the same just called from different places.