For several years I have been a fan of invokable classes, typically to act as action classes for forms and to create jobs for queues etc.
Simple Forms
With regards to simple forms, this works well. The validation and creation code are all contained in one class keeping the code out of the controller. If all you need is validation and a little logic before saving/updating, this model works well. The model breaks down when the complexity of the request goes up.
Invokable Controllers
On a recent freelance project, I needed to validate the request, convert the data and then generate lots of additional values. This Apps calculates the viability of pumps based on the request so there are a lot of fluid dynamic calculations. Once the calculations have been processed, I can again calculate the viability. Only once I have calculated the viability do I save the request.
Naming
My action classes have simple names – createGame, saveUser, – you get the idea. When you read the name of the action, you know what it does and when you look inside, you have an idea about what you will see. This doesn’t work when there are five or six steps that must happen before the “quote” is created.
We get this benefit with invokable controllers as well but rather than the class names telling you what is happening, the method names in the controller describe what is happening. We get all the benefits of invokable action classes without the negative of a giant action class which is doing more than its name suggests.
I rarely need to use invokable controllers but when I do, they are a life saver.
I’ve a detailed post on how I use action classes and how the specific use changes on the structure of the App. If you are a fan of invokable action classes, please give it a read.