The word "service" is often used in the Laravel community, but is it a "design pattern"?
Yes and no.
It is a pattern in the sense that it's a typical approach to offload the logic from the Controller to "somewhere else", that "somewhere" being the Service class.
However, identically to the Action classes, Services are not a core Laravel function, so there's no php artisan make:service
, and developers can name/structure them however they want.
I've seen two main use cases for Service classes:
Case 1. Something like UserService
: A class with multiple methods around a certain Model or other subject (more "loose" pattern)
Case 2. Something like StripeService
: A class that helps to work with external functionality or a 3rd party library that can be replaced with another library in the future (more "strict" pattern)
And let's see both in action.
A typical simple example is this:
app/Http/Controllers/UserController.php:
use App\Http\Requests\StoreUserRequest;use App\Services\UserService; class UserController extends Controller{ public function store(StoreUserRequest $request, UserService $userService) { $userService->store($request->validated()); return redirect()->route('users.index'); } // ...}
Then, inside that UserService
class, you have methods to store users, update users, and perform other operations related to the User model.
app/Services/UserService.php:
namespace App\Services; class UserService { public function store(array $userData): User { $user = User::create($userData); $user->roles()->sync($userData['roles']); // More actions with that user: let's say, 5+ more lines of code // - Upload avatar // - Email to the user // - Notify admins about new user // - Create some data for that user // - and more... return $user; } public function update(array $userData, User $user): User { $user->update($userData); $user->roles()->sync($userData['roles']); // Also, more actions with that user }}
So, you've seen this code...