In Laravel, what is the advantage of single action controllers?

Question

A topic about single action controllers is in the laravel documentation:

https://laravel.com/docs/5.5/controllers#single-action-controllers

My question is, what is the use case where you will use this controllers? How will you structure your controllers if you opt to use single action controllers for all your controllers?

Answer 1

This is an intresting question and my answer is not related to laravel, but to the single vs multiple actions per controller.

I have found when trying to find the use case for a pattern that is new, is to ask the inverse questions, in this case, when is the use case of multiple actions per controller make sense?

The answer usualy comes to:

You have an object that has crud operations (because your using sql) and its convenient to place all the stuff related to that object in one spot.

This is akin to the answer of "I have a hammer, so everything is a screw" and IF your domain is as simple as a thin layer over a crud database, then that is the use case for multiple actions per controller.

What I have found is that any amount of complexity blows up the controllers, no matter how good your model is. The reason is CRUD opperations are apart of your model, not your controller.

We usually think that we will map nicely to a CRUD model in our controller, there are many front end frameworks that work amazing at that, untill....

Look at the most common aspect of applications, users. In the setup your going to have index of users, which I don't know who would look at that page besides admins, and they usualy want extra information. so for the index action, you need admin custom authentication.

Then creation, well, it does not make sense to have an user create an user, you need to ensure the user is not authentication.

Now we talk about reading. What data an admin, other users, current user, and anon user can see is massivily differnt, and will slowly build up in complexity.

Then delete, this is normally rare action, and on some models not needed, but you still put it up, because, well you have a hammer.

The update, do you put password updates in here too? what if the user forgot there password? do you put that in here? No, you make a new action called forgot password. Well now you need update password action. What goes in the update is usually a gigantic mess of hell after a year.

Each pattern has its pros and cons, my general advice is to do multiple actions per controller when your system is trully CRUD OR you will not have to maintain the project for more than a year. If you have any amount of complexity that will have to maintained, avoid the model leaking into the controller and keep them seperate.

Answer 2

Michale Dyrynda seems to sum up the pupose of Single Action Controllers in his blog: https://dyrynda.com.au/blog/single-action-controllers-in-laravel

Conclusion

• Single action controllers are an effective way to wrap up simple functionality into clearly named classes.

• They can be used in instances where you're not necessarily following a RESTful approach; be careful not to separate multiple actions for a single entity across multiple controllers.

• Where you might have previously used a single controller for multiple static pages, you could consider separate named controllers for each static pages.

• You can add other methods to this class, but they should be related to the single action this controller is responsible for.

He also states that, you should only use these when you only need a single action for an entity:

You may consider naming the controller ShowPost as a way of being explicit about the controller's intent but I'd suggest caution with this approach; if you start seeing ShowPost, EditPost, CreatePost, etc controllers creeping into your codebase, I'd reconsider the RESTful approach. More controllers never hurt anybody, but we should be smart about when this is done!