Laravel Controller Code: Move to Model, Service, Action or Job?
Вставка
- Опубліковано 20 сер 2024
- This is probably the no.1 debate in the Laravel community - "where should I put this code". Let me explain my philosophy, based on a practical example.
Original Tweet: / 1480128471032643596
Code repository: github.com/Lar...
Laravel Code Review: Why NOT Use Repository Pattern? • Laravel Code Review: W...
Laravel Services and Repositories: 3 Example Projects • Laravel Services and R...
- - - - -
Support the channel by checking out my products:
- My Laravel courses: laraveldaily.c...
- Laravel QuickAdminPanel: quickadminpane...
- Livewire Kit Components: livewirekit.com
- - - - -
Other places to follow:
- My weekly Laravel newsletter: us11.campaign-...
- My personal Twitter: / povilaskorop - Навчання та стиль
I do always create a directory called "Services" on each module of the application where lands the logic used by the controllers, so in my controllers I just pass The service class name as an argument to the controller method, and then I just call the service methof from the controller, my controller now all contains max 2 lines of code. My models contain only relationships, some overriding functions, and accessors/mutators. I can say this is a good practice
We named this directory "managers", because our "Manager" Classes don't provide real services... Lets say we have Ticket model with TicketController... The TicketManager class "manages" everything that is related to tickets. Also, the word "Service" is already claimed by Laravel core at some places... But I think the approach, independently from naming, is good :)
I totally agree. I also usually make the services methods as static to keep it even simple, so you don't have to instantiate it or use dependency injection
We can use interface
No, you're doing it wrong, you need more abstractions... create another folder inside services called servicing_service, then create another folder inside that called bottle_service then add another folder inside that called micro_service, so pass data through each class to make things simpler and easier to read. The more layers of abstractions you add the simpler your code will be... flawless logic every time.
@@BillClinton228 no, just throw all logic to the views
It’s uncanny how often I’m thinking about a subject in laravel (that I could work more on) and you release a video on that very subject! Thanks as ever Povilas. 👏
In my opinion, "move to model" is never an option, even for small projects. It's not models' responsibility to handle business logic and they should stay anemic. Services usually are the answer, but sometimes a service class handles too many responsibilities and methods. Better to use an action, which will handle a single aspect of the application, optionally injecting other services (each of one handling a specific responsibility).
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.
all programmers confusing this part after learning the basics. they are going to code in the way showing in docs.
For small projects its OK. but for large or medium scale projects will be get more complex, hard to maintain
In My point of view
Models are not business logic, it represents database table. It is a gateway between application and database
WebController, Console Commands, Graphql Mutator, Graphql Query Resolvers, API controllers are receive input and output processed data, Not doing any operations itself. it controls everything between visible input and visible output
Actions Responsible for one specific operations assigned. action may call another action to execute.
Same action can use inside WebController, Console Commands, Graphql Mutator, Graphql Query Resolvers ... etc
I prefer Actions over Services to execute operations
It can be Queable
Services Performing computations over arguments and return its result
..etc
Key point is Split Responsibilities if it going to complex. It will help for maintenance, code reusing and unit testing
Well, that's what I mean with a clear understanding of where what belongs. Thank you for this video, makes a lot more sense now. The Service Class looks the most readable for me. You explain things so well, that I understand things that I do even not understand after reading multiple times. Another big thank you for that! Crystal Clear
I also do like to use Services, i don't know why ppl go with rep pattern for small projects or push methods in model... As you said and i completely agree, model should consist of relations, fields, casts and scopes, all model related stuff...
Perfect video! In this case I would have used a service. TO ME, actions does not return anything. You perfom an action and go back. Services could return something.
In this case an invoice is returned so I would have used a servece. IMHO, of course. :D
Yes, IMHO is the most appropriate word (abbreviation) for this video and comments. And yes, after editing the video I thought about it, that I used Action maybe in not the most intended way - many people use Actions without returns, just as Jobs.
Totally agree with your preference of using Service classes! Love the high level comparison of ‘Model’ and ‘Service’!
Thank you very much for such a clear explanation as always. Thanks to your videos I successfully passed my job interview for Laravel developer position, and explained things related to Laravel even made interviewer suprise :D
Great to hear!
Right on time. Few days ago I was structuring project functionality which can take some time: parse json, download files (~50mb), store them, update db. And I decided Jobs + Queue + Cron. After your video I'm staying with same decision. Thanks for content and QAP :)
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
Your videos are great, I can't even miss one second of them. Thanks for such a high quality content.
Tip: *Use the Command pattern when you want to queue operations, schedule their execution, or execute them remotely.*
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
Thanks for video
I have a project with complex business logic and long-run jobs.
I'm dispatching Events from Controller.
EventServiceProvider class stores the mapping between Listeners and Event (shouldDiscoverEvents = false) where one Event can have multiple Listeners. Job and Listener can be queueable (async) and run in the background.
Inside the controller, I'm validating the Request data, creating/updating the model, and then dispatching the Event.
Contoller -> Event -> Listener(s) -> Service(s)
Contoller -> Event -> Listener(s) -> Service(s) -> Job(s)
Contoller -> Event -> Listener(s) -> Job(s) -> Service(s)
I am quite new to Laravel and this video gives me good knowledge about Laravel. Thank you very much
I am writing all the logic in the controller, now i will follow your code structure. Its good to breakdown code.
This is over my head. I wish I understood more what you are talking about, but it looks way advanced.
It`s very interesting. I like Service too. I have been working with Angular for years and it has the same phylosophy respect with the actions. Usually I use just the methods controller for the logic but if the application is complex, have a long functions and code, it`s good idea sepatarate the logic in other class like Service. I think the same about models is for Eloquents operations...just that. Services it`s good idea for operations like actions. Jobs it`s for especific cases, for when you have to use a queue in a background.
I saw you retweet this subject on Twitter. Thank you for making a video about it!
Very nice video, totally agree as architect to this solution.
Another way is to use a more comprehensive architecture pattern like the hexagonal or clean architecture, it seems difficult to apply that patterns to laravel but is just a meaning of proper layer separation, with that architectures you will end up with a usecase in this particular video scenario with all the concerns and boundaries moved to the laravel/infrastructure layer. But can be overwhelmed for small projects. Anyway I really appreciate that video, can be a light in the dark for many developers, kudos from Italy!
For my projects I try to keep it simple and store the "service" methods on the model file. I find it easier this way. If it is a third party project, I follow whatever convention they have stablished.
I need to agree with Povilas on this one. I have been working on a project where all the logic and methods where put in the model and now the model is 500+ lines of code. It's hard for debugging and it's a mess if want check how something works.
@Ivalin, how do you avoid a service class from becoming 500+ lines of code? I mean if you just move all the methods from a Model to a Service class - what's the difference?
@@QueeeeenZ With some refactoring, in general I like the idea of structuring your code this way.
@@QueeeeenZ This is a good question.
Thank you for the info about the Repository pattern.
According to SRP, Model should not be responsible for anything except data structure. For me, it is better to implement Repository pattern, since I consider Services as classes that stores Controller logic (kinda helpers), but Repositories always contain logic to manipulate or access data from the model
I wish every english speaker talked like you, I can perfectly understand every word!
I totally agree with you. Model is a data container, it shoulden't contain behavior. Of corse it can host data related methods but not behavior ones.
Want more? My Laravel courses membership: laraveldaily.com/courses
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.
This sounds interesting. Do you have tutorial about it? I want to read it further. Thanks.
I agree with your opinion, I think it's easier to maintain a class of services than a whole model overloaded with various types of actions. A possible solution to "fatten" the model with a large number of actions is to segment them into traits according to their relationship with each other, this makes management and maintenance easier, but there will always be the risk of breaking our model. Making any changes to it could affect the performance of the model and affect our app. Great job my friend, thanks for sharing your knowledge with us every day, cheers!
Nice video. I personally use the name service as means to connection with other external services using guzzle, sftp, grpc etc.
I use the name Task (alternative to Action) to separate large logic.
Just my personal choice.
Yup, it's all a personal choice! It may make the difference only if you work in the team, and then your teammates need to understand that naming.
What if contain my logic inside a trait.an use it in my controller.
If that trait is repeatable in at least a few other classes, then sure.
Thank you Sir ! This topic is clearer to me now 👍
Perfect! I've just seen the preview of this video and I absolutely sure that I will use this in my job! Thanks a lot!
Very good, some non-junior stuff at last. Thank you.
I do the same about seperate the logic from controller to another class, I create a class called InvoiceManager instead of InvoiceService, then I use the same functions from that InvoiceManager class for api and web controllers.
So yes, it's a service class, just called differently, all good!
I personally use Controllers to determine the http code that is returned based on result of a service. I use service for actions that write/update the model, and declare functions in models when I want to read specific data with different conditions in said model.
I was looking for this video, fortunately it found me itself 😍
Nice and useful videos. Thanks for your hard work!
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.
My proposal would be to create helper classes which extends model class, and use services for code that can be used in different projects like TwillioService, StripeService, DownloadPdfService etc
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.
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.
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.
I think service class is better because you can put all the logic of the controller inside the service, that way the controller is getting shorter and more readable
Using invoke in action class is cool, you don't have to remember mething name, action class behave as method itself
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.
Just the perfect explination for this topic, thank you!
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'.
Honestly - just use CQS, it's not so hard pattern, put your reads/queries into query classes(most likely interfaces and some implentations), and create commands and handlers for creating invoice, this way you have most clean code you can have.
validation should go to controller but the logic should go to service in my opinion
What about:
# 1. Controller `$order->createInvoice()`,
# 2. Model `function createInvoice() { $invoiceService->createFrom($this) }`,
# 3. Service `function createFrom(Order $order) { // logic }`.
It would be inconsistent. Why not use in #2 Invoice::from($this) ? why use a service in that case?
Also possible, but I think overcomplicated. So you have the code BOTH in the Model AND in Service? I wouldn't personally do that.
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 good explanation ✔️✔️
i think it should be like this controller -> service -> repository -> model
Great video. Thanks Povilas.
Service reminded me the architecture of springboot.
3:43 I think this is going to be difficult to debug. You won't get the log and full back trace of the error.
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.
so, what I learnt today, there is 3 class that suppose to be create,
1. Model. Is a config class for integrate to a database class. So we config its fields, relations, and other querys (that already handle by ORM)
2. Service. Is a set of Actions
3. Controller is a router to what service we would like to do.
4. Action is a set of jobs
5. Jobs is 1 or 2 to do(s)
Am I right?
Mostly yes. But, depending on specific project, you may have freedom to change this logic if you want.
Send model object in job - its bad practice. Better - send order id and extract order from db in job itself.
Agree, if the job is queueable and may happen later, with changed object data
Thanks! Very useful
All these alternatives imply that in the future their functions will be used elsewhere in the project. But in most cases you don't reuse them anywhere and you end up having these one-off classes / methods which is weird to me. In my opinion these one-off classes or methods should be as close to the "calling-class" as possible, like putting them in traits in the same directory or subdirectory with the caller class and make the caller class use that trait, just like the laravel's base controller uses AuthorizesRequests, DispatchesJobs and ValidatesRequests. But again this is just my optical view and I am definitely confused with all these alternatives.
No, not necessarily will be used elsewhere, and I don't see anything bad with one-off classes/methods.
Traits are mostly for REUSABLE things, that you potentially can use in multiple classes.
That's why the most simplified way to handle this - might be not creating controller, just create callable class and put it like this:
$router->post('whatever', Cool::class);
Nice guide. So if you do (heavy) processing but don't need to return anything: use jobs. If you have to return something and you only need 1 method: use actions (but you can use services as well). If you have more than 1 method: use services. One question though. I'm concerned about having a large Services folder with a lot of "miscellaneous" files laying around (not all of them being controller related) and doing impact analysis on these files. When you want to change the behaviour of a service class, how do you track down where it is being used? Do have any thoughts about organizing these files? Should we store controller related service classes in a different location from other service classes?
Without practical example, it's hard to say. But generally, you can structure services into subfolders
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.
Sir.... This video is really helpful for me..... I request for a Saturday car video to speak about as a beginner. How much knowledge on Core PHP to Master a Laravel or To develop packages in laravel. Its more useful if you add learning path you have added for laravel and the testes like that.... Sry for my bad English sir........ Even any in this community help to find the path to master core PHP..... Thanks in advance
To be honest, I would learn the basics of core PHP only (variables, if-statements, loops, OOP - there are thousands of free tutorials online), and then dive into Laravel. I don't think it needs the full video.
Nice video Thank you
Thank you very much Sir! Finally, here I found the answer to my question, which I asked many people. I've been using repositories so far and didn't know it was bad practice already. But how do you feel about architectural patterns like Porto, where we have actions and repositories and tasks. And, does it make sense at all to split the project into containers, each of which has its own route, controller, model, and so on. Or such a solution is only good for large projects.
Yes, I see things like Porto, Lucid, DDD and others mostly for large projects/teams, for smaller projects it's kind of over-engineering just for the sake of "some" structure.
To my knowledge, you don't throw exceptions from your jobs. Cause, when you throw an exception, the job class gets requeued and pulled later. I rather just delete or early return from the job class.
Yes, with jobs, it's a bit more complicated, in the queue they are handled differently. I just want to make the example that you can use jobs in some cases, but in my particular case it wasn't even a fit, so I didn't proceed with that example.
I totally agree with you!
Thank you so much,
i don't think there is universal solution appliable for every project, in my opinion a good programmer knows a lot solutions but knows which one to choose for the task in front of him...
What about
Controller => service => repository => model
I prefer Repository Pattern for putting logic and also coming Abstraction 👍😉
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
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.
If controller is responsible for ALL the logic, it may become too big and hard to read/maintain. It's not that much about controller being short, but it's about "separation of concerns" principle and shorter classes, in general.
Thanks for the video. What I find troubling about the model way is that for example if you use elastic search without laravel bridge you end up with array of objects not models and in order to use some methods you have to convert these 'virgin' objects to actual laravel model objects. This idea comes from an eshop solution that we coded where using eloquent models for products took up a lot of memory and was not efficient when using elastic so we ended up with custom Product model not connected to laravel base model class at all. This idea came from one of the most senior php devs in team. What do you think about that?
Well, your example is very untypical but realistic. So yes, if you see that any other framework/pattern/structure works better or more performant than default Laravel, then of course you're free to move away from conventions like Eloquent and replace with your own base classes.
@@LaravelDaily Indeed but personally i find it very challenging because they you need developers who understand also vanilla php and logic behind it not just laravel
Finding developers is always a challenge :)
If you take on such non-standard projects, you need non-standard developers :)
@@LaravelDaily for a non standard price, that's why i dont think its worth the few mili seconds and ram MB saving. Rather get better VPS. But that's more business and budget domain :) I rembemr how Jonathan Reinink said that people pick technologies such as elastic even though they are not needed. Laravel mysql eloquent can just find you just have to understand queries and rules for memory saving. Also it's not 2000 anymore when the servers were so expensive and limited i guess.
Why don't we just return the invoice number instead of whole object to the controller from action or service?
Sure if you need only the number
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?
ua-cam.com/video/jxHVaz3iOiU/v-deo.html here's the video
Question - if all you do in handling is just responding with certain response, why not just let it bubble up to Handler class and define "render" method there to do the same? IMO, much clearer. Sure, if you want to handle it differently, you can use try/catch.
It's hard to comment on your theoretical thoughts, without a real full practical example with Handler and render. It depends on the exact situation.
@@LaravelDaily In my case, I did a lot of API development where Laravel serves backend for React Native / other mobile stack applications. Usually exception would be handled with JSON response with a certain HTTP code. Usually took shape of extending default Exception class by something like ApiException. It would implement render method that would take injected message and code and transform into response. Since this was for most exceptions, it really cleared up controllers. For those cases where we need something different - yes, then I'd go for try/catch and handle things differently.
Yes, now it makes more sense, with that additional context. Agree to move exception logic to the global handler.
why don't consider observer instead of service for status update or sending notification?
Also possible, yes
very useful channel
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
To avoid such long lines, why can't we use trait instead?
Which long lines would be better in a trait instead of a service? Traits are usually for REUSABLE things, if you use trait in more than one class.
Thanks very nice.
How would this work with a repository implementation and would it be good/bad?
I'm quite a big anti-fan of repository pattern, expressed in a few videos, like this one: ua-cam.com/video/giJcdfW2wC8/v-deo.html
thx u from ukraine !!! =)
But how do you keep your Service class from becoming a "god" object? If you just move all methods from a Model to a Service then that service is now very large - kind of like a place to "dump" all your model related things. So imagine an OrderService class can become huge. How do you avoid that?
If it feels like it’s too much or has too many responsibilities, identify those responsibilities and split into separate classes. Let’s say you have a ProductService that deals with products. Maybe one responsibility is to perform some kind of update, notify someone about that, etc., but another is to generate statistics for a dashboard. So what they have in common is they deal with products, but maybe ProductStatisticsService could be its own class.
Audun answered that already, so my take is similar: if ANY class (no matter Service, Model or anything else) becomes too large, you split it into smaller classes. For services, some functions may become jobs/actions.
I probably will shoot a separate video about God-classes, worth separate discussion.
Great Video @Laravel Daily.
I am using the same structure as you, except that my services contains only static methods instead of regular methods, will having such methods have side effects on the project?
Another question, Is there a name for this structure of having classes with static methods ?
Thank you in advance
Static methods are totally fine if you choose to use them.
I have a few videos about them: www.youtube.com/@LaravelDaily/search?query=static
If I have multiple roles (admin, company owner, company client); should I have each controller namespace different or should I put it all in one controller and define logic per role?
Personal preference
Another solution would be to use traits in your model by grouping the tasks. That way you don't have to create services all over the place while you have separation of concerns. That is if your code is mainly db related.
Maybe some Trait would be a useful with this simple example?
Traits are usually for REPEATING code, if you repeat it in more than one class. I didn't see the repeating parts here in this example.
What about data fetching logic? Should services implement data access on top of Eloquent? Especially if you need a few conditions. Like fetch users who are admins and were created between dates. Or were suspended/deleted. Bloat service with methods for each case? getAdminsCreatedBetween, getDeletedAdmins, getSuspendedAdmins etc. Instead of query builder
It depends on the situation. If your service becomes bloat then refactor it, also it looks like Eloquent Scopes in your case.
@@LaravelDaily that's my point, Eloquent + models + scopes give you a lot of good code to use. And if you remove it from controllers - should you implement almost the same thing inside services, if you need data access and some other logic for a resource? Or use both, service for logic and eloquent for a data access in controllers?
It depends on the situation. My personal experience is that if Controller method has 1-3 actions to make, it's ok to be in Controller, but if it's more complicated - it should be moved "somewhere", and that somewhere depends on what code is moved.
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?
Can be, yes, it's your personal preference
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?
No, it speeds up flexibility and maintainability for other developers in the future.
@@LaravelDaily completely agree. The controller can become extremely large and a challenge to maintain over time. Services are usually the answer for me followed by Jobs. Still to play around with Actions.
Thanks!
Where is Trait?
Povilas, how i insert user id through mass assignment in form request.?
I can't answer that in a short UA-cam comment, without code example
What about when we have request(create form is submited) should we pass whole request to services method create and return what ?
No, ideally you should pass only the data that services actually need to work with.
@@LaravelDaily Thanks for the answer, do you have video or link with example
Search "service" on my channel, quite a few videos about them, not sure if those are the exact examples.
Also, I have this project: laravelexamples.com/tag/services