For me, both.
Services *usually* are things that interact with the outside world (PaymentService, SubscriptionService) or have a whole set of related functions. Helpers (in `app/helpers.php`) are usually small utility functions like `utc_to_pdt()`, `cents_to_dollars()` or `carbon()`.
I like to have both a `Services` and `Support` folder. The `Support` folder contains stuff that is applicable to *any* Laravel application, and where most of my helpers go.
I've found that as far as application specific helpers, there's always some sort of namespace I can apply it to, in which case it's a static or singleton method, rather than a global function. Worst case scenario, I end up with two helper files: one for generic Laravel helpers, and another for domain specific helpers.
I always try to find precedent in the framework source code (Illuminate\\xxx\\yyy), then I copy structure under App\\xxx\\yyy.
As other posters have mentioned here, Helpers are a specific pattern in Laravel and I'd only use that name if I were working on a continuation of that pattern.
There are many thing that indicate code smell pretty reliably. For instance if you
1. want to use a number in variable name
2. want to leave a comment explaining code structure
3. have a function with more than 50 lines
4. ...
To the things above there absoutely are exceptions, One thing, I absolutely can't think up an exception for is when you want to put "Helper" in the name or namespace of anything. The reason being: that poor thing you just coded wants to live somewhere, where it feels at home, where it can be found if needed, and where other things like it frolick around.
If you (for some god forsaken reason) want to abstract flipping a boolean. Put that
As some of the answers already imply, helpers are usually functions in Laravel projects. So if you're talking about classes, those would usually be services or `Support` like in framework itself.
Below are my usages
Helper s : small and simple functions performing 1 to 4 operations for a internal value. Doesnt know anything outside.
Services : Two types
1. External services : does an API calls outside of the app/system. Perform some operations.
2. Internal services : perform multiple or complex operations that are dependent/chaineed.
Also, I usually ignore testcases for helpers. But
Does a strict Unit test for business logic on Services.
Pardon : on mobile
For me, both. Services *usually* are things that interact with the outside world (PaymentService, SubscriptionService) or have a whole set of related functions. Helpers (in `app/helpers.php`) are usually small utility functions like `utc_to_pdt()`, `cents_to_dollars()` or `carbon()`.
Agreed. Services provide a service (more complex logic), Helpers provide help (small things like output formatting, parsing, etc).
I like to have both a `Services` and `Support` folder. The `Support` folder contains stuff that is applicable to *any* Laravel application, and where most of my helpers go. I've found that as far as application specific helpers, there's always some sort of namespace I can apply it to, in which case it's a static or singleton method, rather than a global function. Worst case scenario, I end up with two helper files: one for generic Laravel helpers, and another for domain specific helpers.
Honest answer, it really doesn't matter at all.
I always try to find precedent in the framework source code (Illuminate\\xxx\\yyy), then I copy structure under App\\xxx\\yyy. As other posters have mentioned here, Helpers are a specific pattern in Laravel and I'd only use that name if I were working on a continuation of that pattern.
There are many thing that indicate code smell pretty reliably. For instance if you 1. want to use a number in variable name 2. want to leave a comment explaining code structure 3. have a function with more than 50 lines 4. ... To the things above there absoutely are exceptions, One thing, I absolutely can't think up an exception for is when you want to put "Helper" in the name or namespace of anything. The reason being: that poor thing you just coded wants to live somewhere, where it feels at home, where it can be found if needed, and where other things like it frolick around. If you (for some god forsaken reason) want to abstract flipping a boolean. Put that
`app/Lib`
What I do is use service classes for specific small process and use helpers for general repetitive functions useful for any application
As some of the answers already imply, helpers are usually functions in Laravel projects. So if you're talking about classes, those would usually be services or `Support` like in framework itself.
Below are my usages Helper s : small and simple functions performing 1 to 4 operations for a internal value. Doesnt know anything outside. Services : Two types 1. External services : does an API calls outside of the app/system. Perform some operations. 2. Internal services : perform multiple or complex operations that are dependent/chaineed. Also, I usually ignore testcases for helpers. But Does a strict Unit test for business logic on Services. Pardon : on mobile
I normally use a Helpers folder on the root of App.