Laravel Controller Code: Move to Model, Service, Action or Job?

Can someone explain why the code shouldn't live in the controller? Coming from other languages, that code is in the controller and as is stated the model is the structure of the class and it's relation to the DB.

Thank you so much,

Oops .... Ive been puting them in a form request class😂... Not even a honourable mention 😅

I think its generally considered bad practice to use exceptions to handle validation errors. Exceptions should be reserved for unexpected errors that should not be handled by the application. I'd change error validations from exceptions to a MessageBag instance in the service class, and then catch the error by controller using MessageBag->errors

Thanks a lot Povilas, I was trying to understand a way to separate the logic from my model Class to a Service class and your vídeo really helped me to get it. Thks for sharing

If we follow the SOLID principle then we know that ‘S’ stands for Single Responsibility which means that a class should only be responsible for what it is for. It should never be responsible for any other related actions.

In this example: Order class should only be responsible for cRUD functionality of orders.
It shouldn’t have logic for creating an invoice or sending notifications or anything else.

For these tasks, having service classes is a better solution.

Again, those who have worked with Spring (Java) knows that you can have Service class which then calls Repository class for database related logic.

Off-course you can go further to DAO pattern. So from Repository you call the DAO class which then is used for database related logic.

I wish every english speaker talked like you, I can perfectly understand every word!

what tools you use for documentation of apis in laravel, can we use swagger in laravel?

why don't consider observer instead of service for status update or sending notification?

Great video. I know I'm late to the party, but I think throwing and catching Exception isn't such a great idea. Exception is so broad, you may end up catching a completely unrelated exception. I think it's better to throw and catch a more specific exception, like 'InvalidArgumentException' or 'RuntimeException'.

I agree with this video however I never use actions. IMO if you want to reuse the same logic in a command, controller, job, etc., then the service should provide commands, controllers, and jobs. It keeps the design close to the framework and it makes your services reusable across projects. With actions, you're instantiating a lot of single use classes which are tightly coupled to your project.

For example, if I have an action called ProcessUserPaymentMethod, it seems like a concise action. However, as soon as the requirements change to do something like process a team payment method, or to process additional payment methods like wire transfers, now what? Do I continuing writing new action classes for each case, do I add methods to the action class, or do I rewrite what I have into a service?

My rule of thumb is keep models strictly for data relationships, and model configuration like you said. Use controllers to query the db, delegate logic, and render views. Use services to do all the heavy processing and provide extensions to the framework.

What about:
If you would have a Customer model, that extends CustomerService, and CustomerService extends Eloquent Model. That way you can call a method on the object, for instance $customer->redoVerificationProcess(). No need to put the Customer model in an argument of a service class and no need for auto resolving a service class inside the controller. Also, Customer model will still be tiny and readable for relationships, mutators, scopes etc.

Very good explanation ✔️✔️

What about
Controller => service => repository => model

Thanks! Very useful

Thank you very much for what you have said in this video. I am not an expert in DDD but in you personal opinion, I would like to know if there would be some other actions/services that must be disptached o executed from the order invoice, should they be called in the controller one after the other? or can they be called inside the service? which for me makes more sense that a service or services can be called insider other services in order to communicate between each other.

Nice video Povilas!

validation should go to controller but the logic should go to service in my opinion

Man, such a quality content. I just watch another video of using repository pattern for Laravel application and then I found this, great content brother

Thanks for sharing this information, very good video. I agree with you in keeping the business rules into a service or action.
I couldn't understand one point: if you need to pass the object $orderService as a parameter to the function in the controller, how do you do this in the route or even in the blade side to send it?
Thanks in advance

Tip: Use the Command pattern when you want to queue operations, schedule their execution, or execute them remotely.

Laravel directory structure itself is far from optimal if you plan to make a big project.
when it's a big project which has a big business logic, I use the module structure like in Python frameworks i.e., Django.
This structure for me is the best for big projects, every module has its own views, controllers, models, jobs, events, actions, business logic ..., and you don't have travel back and forth between unlinked directories when you're working on a single module.
I think Laravel in the future should consider this structure and must be an option while setup to choose this structure if you prefer.

Great video. Thanks Povilas.

This is over my head. I wish I understood more what you are talking about, but it looks way advanced.

In my opinion, Model should be thin and contains only database configs, accessor and mutators. All database related (for example CRUD) operations should be in the respected Model Repository. Service class will utilize the model repository and do either database operation or external API call.

How would this work with a repository implementation and would it be good/bad?

is it overkill to use event/listeners for this Povilas?

Thanks!

First question is not where its why? Why cant the code bee in the controller? Does it speed up the framework if we move it?

Thanks very nice.

If all methods' arguments of a service start with a specific class, that's when I decide that the methods should probably be within the class, otherwise it becomes somewhat of a helper class for which you could just use static classes or functions. I don't see a problem with having many methods in a class if they're all specific to the class. Talking about god classes, you'd probably wan't to take a look at Laravel's internals, they're full of them.

I always doing my logic in controller, but after watching this video I'm going to refactoring my controllers. Thanks for the insight 👍

Where is Trait?

I have something observation regarding on using Job with dispatchSync which definitely decrease the execution time of process about 40% instead of puting my logic plainly on controller.

In java or groovy, Services class is all about businesses layer and logic. Do the internal logic in service and call it in controller. Controller should not use complicated logic and sql queries, let the service handle it.

Anyone know the IDE color theme?

Your videos are great, I can't even miss one second of them. Thanks for such a high quality content.

Using invoke in action class is cool, you don't have to remember mething name, action class behave as method itself

Clicked on the LIKE button the moment he started talking about the topic because this was something that always troubled me. Looking forward to more of such videos.

You are a fantastic teacher!

Is it too confident to say that just use service? If later on service becoming cumbersome which requires refactor, just separate them using action and job. So service will be only end point that a controller touches?

Services and Actions arent the same then use Event and Listenners? i mean have they the same purpose?

Why don't we just return the invoice number instead of whole object to the controller from action or service?

Personally, if i go from Service to Action, it's for complexity reasons !
I mean, if you've got a Service class with over 1000 lines of code, then refactoring it into a set of Action classes is not a bad idea.

I create a “packages” folder and create local service providers in that folder. Each service provider package is a git submodule and linked as a composer repository of type “path”. This allows me to go crazy on OOP and only publish what is necessary to my app. It also allows me to reuse services across projects.

Thanks for your video. Your service class is like Reposetory Design pattern. So it is better to rename it and move to reposetory directory and also making interface and ....

very useful channel

very useful channel

Here I am, having written an edtech startup's 6 months worth of code on controllers 😅 Buuut they don't call it MVP for nothing. Make it work, then optimize it as you go 😂

I would rather use your method of creating a Services directory, it seems more readable and easier to manage than the other two, Do you have a tutorial about PEST?