MVC non e quello che pensi
Se chiedi a dieci sviluppatori PHP cos'e MVC, ottieni undici risposte. Per alcuni il Controller e il cervello dell'applicazione. Per altri il Model e solo una classe che wrappa una tabella. Per molti la View e un file che mixa HTML e logica. Nessuna di queste interpretazioni e corretta, e la confusione nasce dal fatto che MVC e stato reinventato decine di volte dalla sua creazione nel 1979 da Trygve Reenskaug per Smalltalk.
L'MVC originale di Smalltalk era pensato per interfacce desktop con input diretto dell'utente. Il "web MVC" che usiamo oggi e una reinterpretazione adattata al ciclo request-response di HTTP. Capire questa distinzione e il primo passo per usare MVC senza abusarne.
I tre componenti: cosa fanno davvero
Model: la logica di business, non la tabella
Il Model non e la classe che rappresenta una riga del database. Quello e un Data Mapper o un Active Record — un pattern di persistenza, non un Model. Il Model nel senso architetturale e l'intero strato di business logic: regole di validazione, calcoli, trasformazioni, interazioni tra entita. In un e-commerce, il Model include la logica di calcolo sconti, la verifica della disponibilita, le regole di spedizione — non solo la classe Order.
Il Model non sa che esiste un browser. Non sa che esiste HTTP. Non sa che esiste una View. E autosufficiente: se rimuovi controller e view, il Model funziona ancora — puoi usarlo da un test, da una CLI, da un'API.
View: presentazione, non logica
La View trasforma i dati del Model in una rappresentazione visuale. HTML, JSON, XML, PDF, SVG — sono tutti output della View. La View non prende decisioni di business: non calcola sconti, non valida input, non decide se un utente e autenticato. Riceve dati già pronti e li formatta.
In Soft PHP MVC, il view engine supporta direttive Blade-like (@if, @foreach, @include) che permettono logica di presentazione — condizioni per mostrare o nascondere elementi — senza mescolarla con logica di business.
Controller: il traduttore, non il cervello
Il Controller e il componente più frainteso. Non e il cervello dell'applicazione — e il traduttore tra HTTP e dominio. Riceve la request, estrae i parametri, chiama il Model (o un Service) per eseguire la logica, e passa il risultato alla View. Un controller ben scritto ha metodi di 5-15 righe: valida, delega, risponde.
Se i tuoi controller hanno 200 righe con query SQL, calcoli e condizioni complesse, il controller sta facendo il lavoro del Model. Questo e il sintomo più comune di MVC mal implementato: il "Fat Controller" che concentra tutta la logica in un punto e rende il sistema non testabile e non riutilizzabile.
MVC in Soft PHP MVC: implementazione concreta
Nel framework, il flusso e esplicito:
- Il Router riceve la request e la mappa a un Controller+metodo tramite attributi PHP 8.4
- Il Middleware Pipeline processa la request (CSRF, auth, rate limiting) prima che arrivi al controller
- Il Controller chiama un Service o un Model, riceve i dati, e li passa alla View
- La View renderizza il template con i dati ricevuti e restituisce la Response
Questa separazione non e accademica: e pratica. Il Service ArticleService può essere usato dal BlogController (HTML), da un endpoint API (JSON), o da un comando CLI (testo). La logica vive nel Service, non nel controller.
I malintesi più comuni
- "Il Model e la classe del database" — No. E l'intero strato di business logic. La persistenza e un dettaglio implementativo del Model.
- "Il Controller decide cosa fare" — No. Il Controller traduce la request e delega. Le decisioni di business vivono nel Model/Service.
- "MVC e sufficiente per qualsiasi applicazione" — No. MVC organizza il flusso request-response. Per domini complessi serve stratificazione aggiuntiva: Service Layer, Repository, Domain Events.
- "Più layer = meglio" — No. Un CRUD semplice con Controller → Model → View funziona perfettamente. Aggiungere Service, Repository e DTO per un blog con 5 pagine e over-engineering.
Quando MVC basta e quando no
- MVC basta per applicazioni web con logica di business moderata: blog, portfolio, siti vetrina, CRUD gestionali semplici
- MVC + Service Layer per applicazioni con logica condivisa tra controller diversi o tra web e CLI
- MVC non basta per domini complessi con molte regole di business, aggregati, eventi — servono architetture più strutturate come Hexagonal o DDD
MVC non e un'architettura completa: e un pattern di separazione del flusso di presentazione. La sua forza e la semplicità. La sua debolezza e che non dice nulla su come organizzare la business logic. Per questo MVC e il punto di partenza, non il punto di arrivo.
Top comments (0)