Controllers

Instead of defining all of your request handling logic as Closures in route files, you may wish to organize this behavior using Controller classes. Controllers can group related request handling logic into a single class. Controllers are stored in the directory.

Basic Controllers

Below is an example of a basic controller class. Note that the controller extends the base controller class included with Laravel. The base class provides a few convenience methods such as the middleware method, which may be used to attach middleware to controller actions:

You can define a route to this controller action like so:

  1. Route::get('user/{id}', '[email protected]');

Now, when a request matches the specified route URI, the show method on the UserController class will be executed. Of course, the route parameters will also be passed to the method.

Controllers & Namespaces

It is very important to note that we did not need to specify the full controller namespace when defining the controller route. Since the RouteServiceProvider loads your route files within a route group that contains the namespace, we only specified the portion of the class name that comes after the App\Http\Controllers portion of the namespace.

If you choose to nest your controllers deeper into the App\Http\Controllers directory, simply use the specific class name relative to the App\Http\Controllers root namespace. So, if your full controller class is App\Http\Controllers\Photos\AdminController, you should register routes to the controller like so:

  1. Route::get('foo', 'Photos\');

If you would like to define a controller that only handles a single action, you may place a single __invoke method on the controller:

  1. <?php
  2. namespace App\Http\Controllers;
  3. use App\User;
  4. use App\Http\Controllers\Controller;
  5. class ShowProfile extends Controller
  6. {
  7. /**
  8. * Show the profile for the given user.
  9. *
  10. * @param int $id
  11. * @return Response
  12. */
  13. public function __invoke($id)
  14. {
  15. return view('user.profile', ['user' => User::findOrFail($id)]);
  16. }

When registering routes for single action controllers, you do not need to specify a method:

  1. Route::get('user/{id}', 'ShowProfile');

  1. Route::get('profile', '[email protected]')->middleware('auth');

However, it is more convenient to specify middleware within your controller's constructor. Using the middleware method from your controller's constructor, you may easily assign middleware to the controller's action. You may even restrict the middleware to only certain methods on the controller class:

  1. class UserController extends Controller
  2. {
  3. /**
  4. * Instantiate a new controller instance.
  5. *
  6. * @return void
  7. */
  8. public function __construct()
  9. {
  10. $this->middleware('auth');
  11. $this->middleware('log')->only('index');
  12. $this->middleware('subscribed')->except('store');
  13. }
  14. }

Controllers also allow you to register middleware using a Closure. This provides a convenient way to define a middleware for a single controller without defining an entire middleware class:

Resource Controllers

Laravel resource routing assigns the typical "CRUD" routes to a controller with a single line of code. For example, you may wish to create a controller that handles all HTTP requests for "photos" stored by your application. Using the make:controller Artisan command, we can quickly create such a controller:

This command will generate a controller at app/Http/Controllers/PhotoController.php. The controller will contain a method for each of the available resource operations.

Next, you may register a resourceful route to the controller:

  1. Route::resource('photos', 'PhotoController');

This single route declaration creates multiple routes to handle a variety of actions on the resource. The generated controller will already have methods stubbed for each of these actions, including notes informing you of the HTTP verbs and URIs they handle.

Actions Handled By Resource Controller

Spoofing Form Methods

Since HTML forms can't make PUT, PATCH, or DELETE requests, you will need to add a hidden _method field to spoof these HTTP verbs. The method_field helper can create this field for you:

  1. {{ method_field('PUT') }}

Partial Resource Routes

When declaring a resource route, you may specify a subset of actions the controller should handle instead of the full set of default actions:

  1. Route::resource('photo', 'PhotoController', ['only' => [
  2. 'index', 'show'
  3. ]]);
  4. Route::resource('photo', 'PhotoController', ['except' => [
  5. 'create', 'store', 'update', 'destroy'
  6. ]]);

By default, all resource controller actions have a route name; however, you can override these names by passing a names array with your options:

  1. Route::resource('photo', 'PhotoController', ['names' => [
  2. 'create' => 'photo.build'
  3. ]]);

Naming Resource Route Parameters

  1. Route::resource('user', 'AdminUserController', ['parameters' => [
  2. 'user' => 'admin_user'
  3. ]]);

The example above generates the following URIs for the resource's show route:

If you need to add additional routes to a resource controller beyond the default set of resource routes, you should define those routes before your call to Route::resource; otherwise, the routes defined by the resource method may unintentionally take precedence over your supplemental routes:

  1. Route::get('photos/popular', '');
  2. Route::resource('photos', 'PhotoController');

Constructor Injection

The Laravel service container is used to resolve all Laravel controllers. As a result, you are able to type-hint any dependencies your controller may need in its constructor. The declared dependencies will automatically be resolved and injected into the controller instance:

  1. <?php
  2. namespace App\Http\Controllers;
  3. use App\Repositories\UserRepository;
  4. class UserController extends Controller
  5. {
  6. /**
  7. * The user repository instance.
  8. */
  9. protected $users;
  10. /**
  11. *
  12. * @return void
  13. */
  14. public function __construct(UserRepository $users)
  15. {
  16. $this->users = $users;
  17. }
  18. }

Of course, you may also type-hint any . If the container can resolve it, you can type-hint it. Depending on your application, injecting your dependencies into your controller may provide better testability.

Method Injection

In addition to constructor injection, you may also type-hint dependencies on your controller's methods. A common use-case for method injection is injecting the Illuminate\Http\Request instance into your controller methods:

  1. <?php
  2. namespace App\Http\Controllers;
  3. use Illuminate\Http\Request;
  4. class UserController extends Controller
  5. {
  6. /**
  7. * Store a new user.
  8. *
  9. * @param Request $request
  10. * @return Response
  11. */
  12. public function store(Request $request)
  13. {
  14. $name = $request->name;
  15. //
  16. }
  17. }

If your controller method is also expecting input from a route parameter, simply list your route arguments after your other dependencies. For example, if your route is defined like so:

  1. Route::put('user/{id}', '');

You may still type-hint the Illuminate\Http\Request and access your id parameter by defining your controller method as follows:

  1. <?php
  2. namespace App\Http\Controllers;
  3. use Illuminate\Http\Request;
  4. class UserController extends Controller
  5. {
  6. /**
  7. * Update the given user.
  8. *
  9. * @param Request $request
  10. * @param string $id
  11. * @return Response
  12. */
  13. public function update(Request $request, $id)
  14. {
  15. //
  16. }
  17. }

Route Caching

If your application is exclusively using controller based routes, you should take advantage of Laravel's route cache. Using the route cache will drastically decrease the amount of time it takes to register all of your application's routes. In some cases, your route registration may even be up to 100x faster. To generate a route cache, just execute the route:cache Artisan command:

    After running this command, your cached routes file will be loaded on every request. Remember, if you add any new routes you will need to generate a fresh route cache. Because of this, you should only run the command during your project's deployment.