Laravel controllers are one of the most important building blocks of a Laravel application. They help organize application logic by keeping request handling separate from routes, models, views, and other parts of the application.
If you are learning Laravel controllers, understanding how they work will make it easier to build clean web applications, REST APIs, CRUD systems, authentication flows, and scalable Laravel projects.
In this guide, we will explore Laravel controllers with examples, including how to create controllers, connect controllers with routes, handle requests, validate data, use dependency injection, create resource controllers, build API controllers, and follow controller best practices.
What Is a Controller in Laravel?
A controller in Laravel is a PHP class responsible for handling incoming HTTP requests and returning an appropriate response.
Instead of placing application logic directly inside routes, Laravel allows developers to move that logic into dedicated controller classes.
For example, you could handle a request directly inside a route:
use App\Models\User;
use Illuminate\Support\Facades\Route;
Route::get('/users', function () {
$users = User::all();
return view('users.index', compact('users'));
});
This approach can work for small applications, but routes can quickly become difficult to maintain when they contain too much logic.
A controller provides a cleaner structure:
use App\Http\Controllers\UserController;
use Illuminate\Support\Facades\Route;
Route::get('/users', [UserController::class, 'index']);
The controller then handles the request:
namespace App\Http\Controllers;
use App\Models\User;
class UserController extends Controller
{
public function index()
{
$users = User::all();
return view('users.index', compact('users'));
}
}
In simple terms:
HTTP Request
│
▼
Route
│
▼
Controller
│
▼
Model / Service
│
▼
Database
│
▼
Response
The controller acts as a coordinator between the incoming request and the application’s logic.
Why Use Controllers in Laravel?
Using controllers provides several advantages:
- Keeps routes clean and readable
- Organizes application logic
- Makes code easier to maintain
- Encourages separation of responsibilities
- Makes CRUD operations easier to structure
- Works naturally with middleware
- Supports dependency injection
- Simplifies API development
- Makes large Laravel applications easier to scale
A good controller should generally coordinate the request rather than contain every piece of business logic.
Where Are Laravel Controllers Located?
Laravel controllers are typically stored inside:
app/
└── Http/
└── Controllers/
├── Controller.php
├── UserController.php
├── ProductController.php
└── OrderController.php
The base Controller class is commonly used as the parent class for application controllers.
For example:
namespace App\Http\Controllers;
class ProductController extends Controller
{
//
}
You can organize controllers into subdirectories when an application becomes larger:
app/
└── Http/
└── Controllers/
├── Admin/
│ ├── UserController.php
│ └── ProductController.php
│
└── Api/
├── AuthController.php
└── ProductController.php
This can make large Laravel applications easier to navigate.
How to Create a Laravel Controller
Laravel provides Artisan commands for generating controllers.
Open your terminal and run:
php artisan make:controller UserController
Laravel will create:
app/Http/Controllers/UserController.php
The generated controller can look like:
namespace App\Http\Controllers;
class UserController extends Controller
{
//
}
You can then add methods to handle different actions.
For example:
namespace App\Http\Controllers;
class UserController extends Controller
{
public function index()
{
return 'User list';
}
public function show()
{
return 'User details';
}
}
Connecting a Controller to a Route
Creating a controller is only the first step. You also need to connect its methods to routes.
For web applications, routes are commonly defined in:
routes/web.php
For APIs, they are commonly defined in:
routes/api.php
A controller method can be connected to a route like this:
use App\Http\Controllers\UserController;
use Illuminate\Support\Facades\Route;
Route::get('/users', [UserController::class, 'index']);
Here:
/usersis the URLUserControlleris the controllerindexis the controller methodGETis the HTTP method
The request flow becomes:
GET /users
│
▼
UserController
│
▼
index()
│
▼
Response
Basic Laravel Controller Example
Let’s create a simple product controller.
First, generate it:
php artisan make:controller ProductController
Then add an index() method:
namespace App\Http\Controllers;
use App\Models\Product;
class ProductController extends Controller
{
public function index()
{
$products = Product::all();
return view('products.index', [
'products' => $products
]);
}
}
Then create the route:
use App\Http\Controllers\ProductController;
Route::get('/products', [ProductController::class, 'index']);
When a user visits:
/products
Laravel calls:
ProductController@index
The controller retrieves products and passes them to the view.
Returning Different Types of Responses
A Laravel controller can return different types of responses depending on the application’s requirements.
Returning a String
public function hello()
{
return 'Hello Laravel!';
}
Returning a View
public function index()
{
return view('products.index');
}
Passing Data to a View
public function index()
{
$products = Product::all();
return view('products.index', compact('products'));
}
Another common approach is:
return view('products.index', [
'products' => $products
]);
Returning JSON
For APIs, controllers commonly return JSON responses:
public function index()
{
$products = Product::all();
return response()->json([
'success' => true,
'data' => $products
]);
}
A typical API response could look like:
{
"success": true,
"data": [
{
"id": 1,
"name": "Laptop",
"price": 799
}
]
}
Laravel Controller Methods
A controller can contain multiple methods.
For example:
class ProductController extends Controller
{
public function index()
{
// Display products
}
public function create()
{
// Display product creation form
}
public function store()
{
// Save product
}
public function show()
{
// Display one product
}
public function edit()
{
// Display edit form
}
public function update()
{
// Update product
}
public function destroy()
{
// Delete product
}
}
These methods are commonly used for CRUD operations.
Laravel Resource Controllers
Laravel provides resource controllers specifically for CRUD applications.
You can generate one using:
php artisan make:controller ProductController --resource
This creates methods for common CRUD operations:
class ProductController extends Controller
{
public function index()
{
//
}
public function create()
{
//
}
public function store(Request $request)
{
//
}
public function show(string $id)
{
//
}
public function edit(string $id)
{
//
}
public function update(Request $request, string $id)
{
//
}
public function destroy(string $id)
{
//
}
}
These methods correspond to standard CRUD operations.
| Method | Purpose | HTTP Method |
|---|---|---|
index() | Display products | GET |
create() | Show create form | GET |
store() | Create product | POST |
show() | Display one product | GET |
edit() | Show edit form | GET |
update() | Update product | PUT/PATCH |
destroy() | Delete product | DELETE |
Using Resource Routes
Instead of defining every CRUD route manually, Laravel allows you to use:
use App\Http\Controllers\ProductController;
Route::resource('products', ProductController::class);
This automatically creates the standard resource routes.
The resulting structure is conceptually:
GET /products
POST /products
GET /products/{product}
GET /products/create
GET /products/{product}/edit
PUT/PATCH /products/{product}
DELETE /products/{product}
This is one of the most useful Laravel controller features for CRUD applications.
Laravel Controllers With Route Model Binding
Laravel supports route model binding, which can automatically resolve a model from a route parameter.
Suppose you have:
Route::get('/products/{product}', [
ProductController::class,
'show'
]);
Instead of manually finding the product:
public function show($id)
{
$product = Product::findOrFail($id);
return view('products.show', compact('product'));
}
You can use route model binding:
public function show(Product $product)
{
return view('products.show', compact('product'));
}
Laravel automatically resolves the corresponding Product model.
This makes controllers shorter and improves readability.
Handling Requests in Laravel Controllers
Laravel provides the Request class for accessing incoming request data.
Import it:
use Illuminate\Http\Request;
Then inject it into the controller method:
public function store(Request $request)
{
$name = $request->name;
return $name;
}
You can also use:
$request->input('name');
For example:
public function store(Request $request)
{
$name = $request->input('name');
$email = $request->input('email');
// Process the request
}
Validating Requests in Laravel Controllers
Input validation is an important part of building secure Laravel applications.
You can validate request data directly:
public function store(Request $request)
{
$validated = $request->validate([
'name' => 'required|string|max:255',
'email' => 'required|email',
'price' => 'required|numeric|min:0',
]);
Product::create($validated);
return redirect('/products');
}
Laravel automatically handles validation failures and returns an appropriate response.
For larger applications, Form Request classes can provide even better separation.
You can create one with:
php artisan make:request StoreProductRequest
Then move validation rules into the request class.
Laravel Controllers With Dependency Injection
Laravel’s service container makes dependency injection straightforward.
Suppose you have a service:
class PaymentService
{
public function process()
{
// Payment logic
}
}
You can inject it into a controller:
use App\Services\PaymentService;
class PaymentController extends Controller
{
public function __construct(
private PaymentService $paymentService
) {
}
public function store()
{
$this->paymentService->process();
return response()->json([
'success' => true
]);
}
}
This is useful when controllers depend on services such as:
- Payment processing
- Email delivery
- Notifications
- External APIs
- File storage
- Business workflows
Dependency injection can make code easier to test and maintain.
Laravel API Controllers
Controllers are also commonly used when building REST APIs.
For example:
namespace App\Http\Controllers\Api;
use App\Http\Controllers\Controller;
use App\Models\Product;
class ProductController extends Controller
{
public function index()
{
return response()->json([
'success' => true,
'data' => Product::all()
]);
}
}
You can then define:
use App\Http\Controllers\Api\ProductController;
Route::get('/products', [ProductController::class, 'index']);
An API controller typically returns JSON rather than Blade views.
Example: Complete Product CRUD Controller
Here is a simplified real-world CRUD example.
namespace App\Http\Controllers;
use App\Models\Product;
use Illuminate\Http\Request;
class ProductController extends Controller
{
public function index()
{
$products = Product::latest()->paginate(10);
return view('products.index', compact('products'));
}
public function store(Request $request)
{
$validated = $request->validate([
'name' => 'required|string|max:255',
'price' => 'required|numeric|min:0',
]);
Product::create($validated);
return redirect()
->route('products.index')
->with('success', 'Product created successfully.');
}
public function show(Product $product)
{
return view('products.show', compact('product'));
}
public function update(Request $request, Product $product)
{
$validated = $request->validate([
'name' => 'required|string|max:255',
'price' => 'required|numeric|min:0',
]);
$product->update($validated);
return redirect()
->route('products.index')
->with('success', 'Product updated successfully.');
}
public function destroy(Product $product)
{
$product->delete();
return redirect()
->route('products.index')
->with('success', 'Product deleted successfully.');
}
}
This example demonstrates several important Laravel features:
- Controller methods
- Request validation
- Eloquent models
- Route model binding
- Pagination
- Redirect responses
- Named routes
- CRUD operations
Controllers vs Routes
A common question among Laravel beginners is whether logic should be written inside routes or controllers.
| Feature | Route Closure | Controller |
|---|---|---|
| Small prototype | Good | Good |
| Simple response | Good | Sometimes unnecessary |
| Large application | Difficult to maintain | Recommended |
| CRUD operations | Less organized | Excellent |
| API development | Possible | Recommended |
| Reusable logic | Limited | Better structure |
| Testing | Possible | Easier to organize |
| Separation of concerns | Limited | Better |
For simple routes such as:
Route::get('/health', function () {
return 'OK';
});
A controller may not be necessary.
For application features such as users, products, orders, payments, and bookings, controllers generally provide a cleaner structure.
Controller vs Model vs Service
Understanding responsibilities is important when building scalable Laravel applications.
| Component | Main Responsibility |
|---|---|
| Route | Maps URL to application action |
| Controller | Handles request and coordinates response |
| Model | Represents data and database interactions |
| Service | Handles reusable business logic |
| Form Request | Handles validation and authorization |
| Resource | Transforms API responses |
A healthy architecture can look like:
Request
│
▼
Route
│
▼
Controller
│
├──── Form Request
│
▼
Service
│
▼
Model
│
▼
Database
The goal is not to make every controller extremely small at all costs. The goal is to keep each class focused on a clear responsibility.
Fat Controllers vs Clean Controllers
One of the most common problems in Laravel applications is the “fat controller.”
A controller becomes problematic when it handles:
- Validation
- Database queries
- Payment processing
- Emails
- Notifications
- External APIs
- Complex calculations
- Business rules
- File processing
all inside a single method.
For example, avoid creating a method like:
public function checkout(Request $request)
{
// Validate request
// Calculate taxes
// Calculate discounts
// Process payment
// Create order
// Update inventory
// Send email
// Send notification
// Call external API
// Return response
}
Instead, move complex responsibilities into dedicated classes:
CheckoutController
│
├── CheckoutService
├── PaymentService
├── OrderService
├── InventoryService
└── NotificationService
The controller can then focus on coordinating the request.
Common Mistakes When Using Laravel Controllers
1. Putting Too Much Logic in Controllers
Controllers should not become massive business-logic containers.
If a method becomes difficult to understand, consider extracting logic into services or other dedicated classes.
2. Skipping Validation
Never assume that incoming user data is valid.
Bad:
public function store(Request $request)
{
Product::create($request->all());
}
Better:
public function store(Request $request)
{
$validated = $request->validate([
'name' => 'required|string|max:255',
'price' => 'required|numeric|min:0',
]);
Product::create($validated);
}
Only accept the fields your application actually expects.
3. Using $request->all() Carelessly
Using all incoming request data can introduce unwanted fields into your application logic.
Prefer:
$validated = $request->validate([
'name' => 'required|string',
'price' => 'required|numeric',
]);
Then:
Product::create($validated);
4. Making Controllers Responsible for Everything
If your controller contains hundreds or thousands of lines, it is probably time to separate responsibilities.
Consider using:
- Service classes
- Form Requests
- API Resources
- Jobs
- Events
- Policies
- Repositories where genuinely useful
5. Ignoring Route Model Binding
Instead of repeatedly doing:
$product = Product::findOrFail($id);
consider:
public function show(Product $product)
{
//
}
when Laravel’s route model binding fits the use case.
Laravel Controller Best Practices
Here are some practical Laravel controller best practices for modern applications.
1. Keep Controllers Focused
A controller should primarily coordinate requests and responses.
2. Use Form Requests for Complex Validation
Instead of putting large validation rules into controller methods, create dedicated Form Request classes.
3. Use Route Model Binding
It reduces repetitive model lookup code and makes controller methods cleaner.
4. Use Dependency Injection
Inject services and dependencies instead of manually creating them inside controller methods.
5. Avoid Duplicate Logic
If the same business logic appears in multiple controllers, consider extracting it into a reusable service.
6. Use Resource Controllers for CRUD
Laravel resource controllers provide a predictable structure for standard CRUD applications.
7. Keep API Controllers Consistent
Use consistent response formats, validation, authentication, authorization, and HTTP status codes.
8. Test Controller Behavior
Controllers should be covered by appropriate feature or integration tests, especially for important application workflows.
Real-World Example: E-Commerce Application
Imagine you are building an e-commerce application.
A product controller might handle:
ProductController
│
├── index()
│ └── List products
│
├── show()
│ └── Display product
│
├── store()
│ └── Create product
│
├── update()
│ └── Update product
│
└── destroy()
└── Delete product
An order controller might handle:
OrderController
│
├── index()
├── show()
├── store()
├── update()
└── destroy()
For complicated checkout logic, the controller could delegate to:
CheckoutController
│
▼
CheckoutService
│
├── PaymentService
├── OrderService
└── InventoryService
This structure makes the application easier to maintain as features grow.
A Simple Laravel Controller Architecture
For a medium-sized Laravel application, a practical structure might look like:
app/
│
├── Http/
│ ├── Controllers/
│ │ ├── AuthController.php
│ │ ├── ProductController.php
│ │ └── OrderController.php
│ │
│ ├── Requests/
│ │ ├── StoreProductRequest.php
│ │ └── UpdateProductRequest.php
│ │
│ └── Resources/
│ └── ProductResource.php
│
├── Models/
│ ├── Product.php
│ └── Order.php
│
└── Services/
├── PaymentService.php
└── OrderService.php
This is not a requirement for every Laravel project. The right structure depends on the size and complexity of the application.
Key Takeaways
Here are the most important things to remember about Laravel controllers:
- Controllers handle application requests and coordinate responses.
- They help keep route files clean.
- Controllers can return views, JSON, redirects, and other responses.
- Resource controllers are useful for CRUD applications.
- Route model binding reduces repetitive model lookup code.
- Request validation should happen before processing user input.
- Form Requests are useful for complex validation.
- Dependency injection helps keep controllers flexible and testable.
- Complex business logic should generally be moved into dedicated services.
- Avoid creating extremely large “fat controllers.”
- Consistent controller structure makes Laravel applications easier to maintain.
Frequently Asked Questions About Laravel Controllers
1. What is a controller in Laravel?
A Laravel controller is a PHP class that handles incoming HTTP requests and coordinates the application’s response. Controllers help organize application logic and prevent route files from becoming unnecessarily complex.
2. How do I create a controller in Laravel?
You can create a Laravel controller using Artisan:
php artisan make:controller UserController
Laravel will generate the controller inside:
app/Http/Controllers/
3. What is a resource controller in Laravel?
A resource controller is a controller designed around standard CRUD operations. Laravel can automatically generate methods such as index, create, store, show, edit, update, and destroy.
You can generate one with:
php artisan make:controller ProductController --resource
4. How do I connect a Laravel controller to a route?
Import the controller and define the controller method in your route:
use App\Http\Controllers\ProductController;
Route::get('/products', [
ProductController::class,
'index'
]);
Laravel will call the index() method when the route receives a matching request.
5. Can Laravel controllers return JSON?
Yes. Controllers are commonly used to return JSON responses for REST APIs:
return response()->json([
'success' => true,
'data' => $products
]);
6. Should business logic be inside a Laravel controller?
Simple application logic can be handled directly in a controller. However, complex or reusable business logic is generally better placed in dedicated service classes or other appropriate components.
This helps prevent controllers from becoming difficult to maintain.
7. What is route model binding in Laravel?
Route model binding allows Laravel to automatically resolve a route parameter into a model instance.
For example:
public function show(Product $product)
{
return $product;
}
Laravel can automatically retrieve the corresponding Product model based on the route parameter.
8. What is the difference between a Laravel controller and a model?
A controller handles application requests and coordinates responses, while a model represents application data and interacts with the database through Laravel’s Eloquent ORM.
A typical flow is:
Route → Controller → Model → Database
Conclusion
Laravel controllers provide a clean and organized way to handle application requests. They sit between routes and the rest of the application, making it easier to separate HTTP request handling from database operations, validation, business logic, and response formatting.
For beginners, the most important concepts to learn are creating Laravel controllers, connecting controllers to routes, handling requests, validating input, using resource controllers, and working with route model binding.
As your Laravel application grows, focus on keeping controllers readable and focused. Use Form Requests for validation, services for complex business logic, models for data operations, and API Resources when transforming API responses.
When these responsibilities are separated properly, your Laravel application becomes easier to understand, test, maintain, and scale.
