---
title: "Controller base Laravel 12: da AuthorizesRequests e ValidatesRequests impliciti a Form Request, Gate e composizione esplicita"
description: "Laravel 11 PR #6188 ha rimosso AuthorizesRequests e ValidatesRequests dal Controller base. Form Request (L5.0+) e Gate::authorize() sostituiscono i trait impliciti."
canonical: "https://www.mauriziofonte.it/blog/post/modernizzare-controller-laravel-refactoring-base-class-l12-traits.html"
author: "Maurizio Fonte"
date: "2025-03-12T09:26:34+01:00"
modified: "2026-04-14T17:48:55+02:00"
section: "Laravel"
tags: ["Laravel", "Refactoring"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

# [Controller base Laravel 12: da AuthorizesRequests e ValidatesRequests impliciti a Form Request, Gate e composizione esplicita](https://www.mauriziofonte.it/blog/post/modernizzare-controller-laravel-refactoring-base-class-l12-traits.html)

Mercoledì 12 Marzo 2025, alle 09:26 ![Controller base Laravel 12: da AuthorizesRequests e ValidatesRequests impliciti a Form Request, Gate e composizione esplicita](https://www.mauriziofonte.it/image/001530200-modernizzare-controller-laravel-refactoring-base-class-l12-traits.jpg)

In un progetto di lead generation per il mercato europeo, l'aggiornamento da Laravel 10 a Laravel 12 ha prodotto 47 errori `Call to undefined method` in 23 controller. Tutti chiamavano `$this->authorize()` o `$this->validate()` - metodi forniti dai trait `AuthorizesRequests` e `ValidatesRequests` che in Laravel 9/10 erano inclusi nella classe base `Controller`. Taylor Otwell ha rimosso entrambi nel [PR #6188](https://github.com/laravel/laravel/pull/6188) ("Slim skeleton"), con una motivazione diretta nel [PR #6172](https://github.com/laravel/laravel/pull/6172): "Validation using `$this->validate` in controllers has not been documented in some time. `$this->authorize` can simply be `Gate::authorize`." Il principio sottostante è quello che il [Gang of Four](https://en.wikipedia.org/wiki/Design_Patterns) ha formalizzato nel 1995: "Favor object composition over class inheritance" - le dipendenze implicite ereditate nascondono accoppiamento, le dipendenze esplicite composte lo rendono visibile.

## Cosa è cambiato nella classe base Controller tra Laravel 10 e Laravel 12?

Le [release notes di Laravel 11](https://laravel.com/docs/11.x/releases) documentano il cambiamento: "The base controller included in new Laravel applications has been simplified. It no longer extends Laravel's internal Controller class, and the AuthorizesRequests and ValidatesRequests traits have been removed." La timeline delle rimozioni è progressiva: `DispatchesJobs` è stato rimosso in Laravel 10 (commit `f62d260`, gennaio 2023), `AuthorizesRequests` e `ValidatesRequests` in Laravel 11 (PR #6188, novembre 2023). Il Controller base è passato da classe con 3 trait e un'estensione di `Illuminate\Routing\Controller` a una classe astratta vuota:

```php
/* Laravel 9/10 - Controller con trait impliciti */
namespace App\Http\Controllers;

use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Routing\Controller as BaseController;

abstract class Controller extends BaseController
{
    use AuthorizesRequests, ValidatesRequests;
    ## Ogni controller figlio eredita $this->authorize() e $this->validate()
    ## anche se non li usa mai - accoppiamento implicito
}

/* Laravel 11/12 - Controller minimale */
namespace App\Http\Controllers;

abstract class Controller
{
    ## Nessun trait, nessuna estensione - composizione esplicita
}

/* PRIMA: controller L10 con validate/authorize impliciti */
class PostController extends Controller
{
    public function store(Request $request): JsonResponse
    {
        $this->authorize('create', Post::class);
        $data = $this->validate($request, [
            'title' => 'required|string|max:255|unique:posts',
            'body'  => 'required|string',
        ]);
        $post = $request->user()->posts()->create($data);
        return PostResource::make($post)->response()->setStatusCode(201);
    }
}

/* DOPO: controller L12 con Form Request + Gate espliciti */
class PostController extends Controller
{
    public function store(StorePostRequest $request): JsonResponse
    {
        ## Validazione e autorizzazione già eseguite dalla Form Request
        ## Il controller orchestra, non valida né autorizza
        $post = $request->user()->posts()->create($request->validated());
        return PostResource::make($post)->response()->setStatusCode(201);
    }
}

/* app/Http/Requests/StorePostRequest.php */
class StorePostRequest extends FormRequest
{
    public function authorize(): bool
    {
        return $this->user()->can('create', Post::class);
    }

    public function rules(): array
    {
        return [
            'title' => 'required|string|max:255|unique:posts',
            'body'  => 'required|string',
        ];
    }
}
```

Il controller "dopo" non ha bisogno di alcun trait. La [Form Request](https://laravel.com/docs/12.x/validation#form-request-validation), introdotta in Laravel 5.0 (febbraio 2015), gestisce sia validazione che autorizzazione in una classe dedicata, iniettata automaticamente dal [Service Container](https://www.mauriziofonte.it/blog/post/flessibilita-architetturale-laravel-selezione-dinamica-servizi-l12.html). Se la validazione fallisce, Laravel restituisce automaticamente HTTP 422; se l'autorizzazione fallisce, HTTP 403 - senza codice nel controller.

## Come migrare i controller esistenti da Laravel 10 a Laravel 12?

La [guida di upgrade](https://laravel.com/docs/11.x/upgrade) di Laravel 11 non impone un approccio specifico - il vecchio Controller con trait funziona ancora se lo mantieni nel tuo progetto. Ma ci sono tre strategie con trade-off diversi. La prima (quick fix) è riaggungere i trait al Controller base: ripristina il funzionamento, ma rinuncia al beneficio della composizione esplicita. La seconda è aggiungere i trait solo ai controller che li usano: rende visibili le dipendenze, ma è transitoria. La terza (best practice) è sostituire `$this->validate()` con Form Request e `$this->authorize()` con [Gate::authorize()](https://laravel.com/docs/12.x/authorization#via-the-gate-facade): elimina la necessità dei trait. La documentazione ufficiale sull'[autorizzazione](https://laravel.com/docs/12.x/authorization) chiarisce che `$this->authorize()` e `Gate::authorize()` sono funzionalmente identici - il trait è un convenience wrapper.

Per controller con una singola azione complessa, i [Single Action Controller](https://laravel.com/docs/12.x/controllers#single-action-controllers) con `__invoke()` si combinano naturalmente con il Controller base vuoto - ogni controller è un'unità autocontenuta senza bagaglio ereditato. Come discusso nell'articolo sul [Service Layer](https://www.mauriziofonte.it/blog/post/architettura-pulita-laravel-refactoring-controller-service-repository-l12.html), il controller ideale in Laravel 12 orchestra: delega la validazione alla Form Request, l'autorizzazione alla Policy/Gate, la logica di business al servizio. Rimangono 3-5 righe di codice.

## Errori comuni nella migrazione dei controller Laravel

Il primo errore è riaggungere i trait al Controller base per default senza valutare se servono. In un'applicazione con 40 controller, tipicamente solo 10-15 usano `$this->authorize()` e `$this->validate()`. Reimportare i trait nella classe base per 15 controller che li usano significa accoppiarli implicitamente anche nei 25 che non li usano - esattamente il problema che Laravel 11 ha risolto.

Il secondo è non cercare le chiamate ai trait prima dell'upgrade. Un `grep -r '$this->authorize\|$this->validate' app/Http/Controllers/` identifica tutti i punti di impatto in secondi. Senza questa ricerca, gli errori emergono in produzione - tipicamente nelle route meno testate.

Il terzo è ignorare le [Form Request](https://www.mauriziofonte.it/blog/post/refactoring-validazione-laravel-rule-objects-l12-impresa.html) e continuare a validare inline nei controller. La validazione inline (`$request->validate([...])`, disponibile sull'oggetto Request senza trait) funziona, ma sparpaglia le regole di validazione nei controller invece di centralizzarle in classi dedicate. In un gestionale con 50 endpoint, le stesse regole di validazione per un campo "codice_fiscale" appaiono in 8 controller diversi. Una Form Request condivisa elimina la duplicazione.

Il quarto è non convertire `$this->authorize()` in `Gate::authorize()` quando si rimuovono i trait. La differenza è solo sintattica - entrambi lanciano `AuthorizationException` (convertita in HTTP 403) - ma `Gate::authorize()` rende esplicita la dipendenza dal sistema di autorizzazione. Robert C. Martin [definisce](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) le dipendenze esplicite come prerequisito della Clean Architecture: "Source code dependencies can only point inwards." Un controller che dipende implicitamente da un trait ereditato viola questa regola; un controller che importa esplicitamente `Gate` la rispetta.

La migrazione dei controller è il complemento naturale della [ristrutturazione dello skeleton applicativo](https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html) da Laravel 10 a 12 - entrambi seguono la stessa filosofia di Taylor Otwell: "take the skeleton back down to a slimmer foundation." I [middleware](https://www.mauriziofonte.it/blog/post/laravel-12-middleware-avanzati-sicurezza-logica-business-pmi-refactoring.html) completano il quadro gestendo le responsabilità cross-cutting che non appartengono né al controller né alla Form Request. Per conoscere il mio approccio al refactoring architetturale Laravel, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se i tuoi controller ereditano trait che non usano e la validazione è duplicata in decine di endpoint, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'inventario delle dipendenze implicite e dalla migrazione verso composizione esplicita.

Dall'articolo al lavoro vero

Se il codice di cui parla questo articolo è il tuo

Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione.

[Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteFat Controller in Laravel 12: dal controller da 200 righe a Service Layer, Action pattern e Dependency Injection11 Marzo 2025](https://www.mauriziofonte.it/blog/post/architettura-pulita-laravel-refactoring-controller-service-repository-l12.html)[Articolo successivo »Middleware Laravel 12: da Kernel.php a bootstrap/app.php con security headers, rate limiting e terminable middleware13 Marzo 2025](https://www.mauriziofonte.it/blog/post/laravel-12-middleware-avanzati-sicurezza-logica-business-pmi-refactoring.html)

### Articoli correlati a Controller base Laravel 12: da AuthorizesRequests e ValidatesRequests impliciti a Form Request, Gate e composizione esplicita

- [Validazione dei dati in ingresso in applicazioni Laravel: oltre le regole base per la robustezza dei gestionali](https://www.mauriziofonte.it/blog/post/laravel-validazione-dati-input-custom-rule-form-request-sicurezza-gestionali.html)

  Negli applicativi gestionali per PMI, la validazione dei dati in ingresso è una prima linea di difesa spesso sottovalutata. Un semplice set di · 20 Gennaio 2025

  ![Validazione dei dati in ingresso in applicazioni Laravel: oltre le regole base per la robustezza dei gestionali](https://www.mauriziofonte.it/image/001130070-laravel-validazione-dati-input-custom-rule-form-request-sicurezza-gestionali.jpg)
- [API REST e applicativi gestionali Laravel: come le vulnerabilità legacy minacciano le PMI e la via per una sicurezza moderna](https://www.mauriziofonte.it/blog/post/api-rest-gestionali-laravel-sicurezza-pmi-vulnerabilita-legacy.html)

  Le API REST dei gestionali Laravel legacy possono nascondere vulnerabilità gravi: autenticazione debole, SQL injection, IDOR, assenza di rate · 27 Gennaio 2025

  ![API REST e applicativi gestionali Laravel: come le vulnerabilità legacy minacciano le PMI e la via per una sicurezza moderna](https://www.mauriziofonte.it/image/001290070-api-rest-gestionali-laravel-sicurezza-pmi-vulnerabilita-legacy.jpg)
- [Validazione in Laravel 12: da closure inline a Rule Objects con ValidationRule per regole testabili, riutilizzabili e type-safe](https://www.mauriziofonte.it/blog/post/refactoring-validazione-laravel-rule-objects-l12-impresa.html)

  L'interfaccia ValidationRule, introdotta in Laravel 10, ha sostituito la vecchia Rule con passes /message e InvokableRule, entrambe deprecate. · 21 Febbraio 2025

  ![Validazione in Laravel 12: da closure inline a Rule Objects con ValidationRule per regole testabili, riutilizzabili e type-safe](https://www.mauriziofonte.it/image/001410070-refactoring-validazione-laravel-rule-objects-l12-impresa.jpg)
- [Gestione errori API Laravel 12: da stack trace in produzione a Problem Details RFC 9457 con renderable exceptions](https://www.mauriziofonte.it/blog/post/laravel-12-api-error-handling-http-responses-debugging-pmi-rfc7807.html)

  RFC 9457 luglio 2023, IETF Standards Track ha sostituito RFC 7807 come standard per i dettagli di errore nelle API HTTP, definendo il media type · 14 Marzo 2025

  ![Gestione errori API Laravel 12: da stack trace in produzione a Problem Details RFC 9457 con renderable exceptions](https://www.mauriziofonte.it/image/001550070-laravel-12-api-error-handling-http-responses-debugging-pmi-rfc7807.jpg)
- [Testing di API Laravel con Pest 3 nel 2026: dataset, mutation testing e CI per PMI che vogliono dormire](https://www.mauriziofonte.it/blog/post/laravel-pest-api-testing-pmi-backend-stabilita-affidabilita-ci-cd.html)

  Pest 3 ha portato mutation testing, dataset, arch presets e nested describe nel testing PHP. Per le PMI con API Laravel in produzione il problema · 20 Marzo 2025

  ![Testing di API Laravel con Pest 3 nel 2026: dataset, mutation testing e CI per PMI che vogliono dormire](https://www.mauriziofonte.it/image/001590070-laravel-pest-api-testing-pmi-backend-stabilita-affidabilita-ci-cd.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Controller base Laravel 12: da AuthorizesRequests e ValidatesRequests impliciti a Form Request, Gate e composizione esplicita", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/modernizzare-controller-laravel-refactoring-base-class-l12-traits.html

Pubblicato: 2025-03-12 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.