Questo materiale fa parte della serie "Introduzione allo sviluppo aziendale". Articoli precedenti:
In questo articolo impareremo a conoscere qualcosa chiamato MVC. Parleremo di cos'è MVC, toccheremo la sua storia, esploreremo le idee e i concetti di base incorporati in MVC, daremo uno sguardo passo dopo passo a come suddividere un'applicazione in moduli Model, View e Controller, scriveremo un piccola applicazione Web che utilizza Spring Boot e, utilizzando Spring MVC come esempio, vedere come i dati vengono inviati dal codice Java alle pagine HTML. Per comprendere questo materiale, devi avere familiarità con i modelli di design, in particolare l'osservatore e la facciata. E avere familiarità con le richieste e le risposte HTTP, comprendere le basi dell'HTML e sapere cosa sono le annotazioni Java. Prendi una tazza di caffè e uno spuntino e mettiti comodo. Cominciamo.
Da tutto ciò, possiamo trarre una conclusione logica. Un sistema complesso deve essere suddiviso in moduli. Descriviamo brevemente i passaggi per ottenere questa separazione.
Ed è così che arriviamo a un'applicazione composta da tre moduli chiamati modello, vista e controller. Riassumiamo:
- sulla rete
- sull'architettura del software
- su HTTP/HTTPS
- sulle basi di Maven
- sui servlet (scrittura di una semplice applicazione web)
- sui contenitori servlet

Storia di MVC
Le idee alla base di MVC sono state formulate da Trygve Reenskaug mentre lavorava allo Xerox PARC alla fine degli anni '70. A quei tempi, lavorare con i computer richiedeva una laurea e uno studio costante di una voluminosa documentazione. Il compito risolto da Reenskaug insieme a un gruppo di sviluppatori molto forti è stato quello di semplificare l'interazione di un utente ordinario con il computer. Era necessario creare strumenti che, da un lato, fossero estremamente semplici e comprensibili e, dall'altro, rendessero possibile il controllo di computer e applicazioni complesse. Reenskaug ha lavorato in un team che ha sviluppato un computer portatile "per bambini di tutte le età": il Dynabook e il linguaggio SmallTalk sotto la guida di Alan Kay. Fu allora che furono stabiliti i concetti di un'interfaccia amichevole. In molti aspetti, il lavoro svolto da Reenskaug e dal suo team ha influenzato l'evoluzione della sfera IT. Ecco un fatto interessante che non si applica direttamente a MVC, ma illustra il significato di questi sviluppi. Alan Kaydisse, "Quando sono arrivato in Apple per la prima volta, che era nell'84, il Mac era già uscito e Newsweek mi ha contattato e mi ha chiesto cosa ne pensassi del Mac. Ho detto: 'Bene, il Mac è il primo personal computer abbastanza buono da essere criticato.' Quindi, dopo aver annunciato l'iPhone nel 2007, me l'ha presentato e me l'ha consegnato. Ha detto: "Alan, è abbastanza buono per essere criticato?" E io ho detto: 'Steve, rendilo grande quanto un tablet e dominerai il mondo'". Dopo 3 anni, il 27 gennaio 2010, Apple ha presentato l'iPad con una diagonale di 9,7 pollici. In altre parole, Steve Jobs ha seguito quasi esattamente il consiglio di Alan Kay. Il progetto di Reenskaug è durato 10 anni. Ma la prima pubblicazione su MVC è venuta alla luce dopo altri 10 anni. Martin Fowler, autore di numerosi libri e articoli sull'architettura del software, afferma di aver studiato MVC utilizzando una versione funzionante di Smalltalk. Poiché non c'erano informazioni su MVC dalla fonte originale per molto tempo e per molti altri motivi, è apparso un gran numero di interpretazioni diverse di questo concetto. Di conseguenza, molti considerano MVC un modello di progettazione. Meno comunemente, MVC è chiamato pattern composito o una combinazione di diversi pattern che lavorano insieme per creare applicazioni complesse. Ma, come accennato in precedenza, MVC è in realtà principalmente un insieme di idee/principi/approcci architettonici che possono essere implementati in vari modi utilizzando modelli diversi... Successivamente, considereremo le idee principali incorporate nel concetto MVC. e per molti altri motivi, sono apparse un gran numero di interpretazioni diverse di questo concetto. Di conseguenza, molti considerano MVC un modello di progettazione. Meno comunemente, MVC è chiamato pattern composito o una combinazione di diversi pattern che lavorano insieme per creare applicazioni complesse. Ma, come accennato in precedenza, MVC è in realtà principalmente un insieme di idee/principi/approcci architettonici che possono essere implementati in vari modi utilizzando modelli diversi... Successivamente, considereremo le idee principali incorporate nel concetto MVC. e per molti altri motivi, sono apparse un gran numero di interpretazioni diverse di questo concetto. Di conseguenza, molti considerano MVC un modello di progettazione. Meno comunemente, MVC è chiamato pattern composito o una combinazione di diversi pattern che lavorano insieme per creare applicazioni complesse. Ma, come accennato in precedenza, MVC è in realtà principalmente un insieme di idee/principi/approcci architettonici che possono essere implementati in vari modi utilizzando modelli diversi... Successivamente, considereremo le idee principali incorporate nel concetto MVC.MVC: Idee e principi di base
- VC è un insieme di idee e principi architettonici per la costruzione di sistemi informativi complessi con un'interfaccia utente
- MVC è un'abbreviazione che sta per: Model-View-Controller

Passaggio 1. Separare la logica di business dell'applicazione dall'interfaccia utente
L'idea principale di MVC è che qualsiasi applicazione con un'interfaccia utente può essere suddivisa in 2 moduli: un modulo responsabile dell'implementazione della logica aziendale e l'interfaccia utente. Il primo modulo implementerà le funzionalità principali dell'applicazione. Questo modulo è il cuore del sistema, dove viene implementato il modello di dominio dell'applicazione. Nel paradigma MVC, questo modulo è la lettera M, cioè il modello. Il secondo modulo implementa l'intera interfaccia utente, compresa la logica per visualizzare i dati all'utente e gestire l'interazione dell'utente con l'applicazione. L'obiettivo principale di questa separazione è garantire che il nucleo del sistema (il "modello" nella terminologia MVC) possa essere sviluppato e testato in modo indipendente. Dopo aver effettuato questa separazione, l'architettura dell'applicazione si presenta così:
Passaggio 2 Utilizzare il pattern dell'osservatore per rendere il modello ancora più indipendente e per sincronizzare le interfacce utente
Qui abbiamo 2 obiettivi:- Ottieni un'indipendenza ancora maggiore per il modello
- Sincronizzare le interfacce utente
Passaggio 3 Separare l'interfaccia in visualizzazione e controller
Continuiamo a dividere l'applicazione in moduli, ma ora a un livello inferiore nella gerarchia. In questa fase, l'interfaccia utente (che abbiamo separato in un modulo distinto nel passaggio 1) è suddivisa in una vista e un controller. Disegnare una linea netta tra la vista e il controller è difficile. Se diciamo che la vista è ciò che vede l'utente e il controller è il meccanismo che consente all'utente di interagire con il sistema, potresti evidenziare una contraddizione. Gli elementi di controllo, come i pulsanti su una pagina Web o una tastiera virtuale sullo schermo di un telefono, fanno sostanzialmente parte del controller. Ma sono visibili all'utente come qualsiasi parte della vista. Quello di cui stiamo veramente parlando qui è la separazione funzionale. Il compito principale dell'interfaccia utente è facilitare l'interazione dell'utente con il sistema.- output e visualizzare comodamente le informazioni di sistema per l'utente
- inserire dati utente e comandi (comunicarli al sistema)

- Secondo i principi del paradigma MVC, un sistema deve essere suddiviso in moduli.
- Il modulo più importante e indipendente dovrebbe essere il modello.
- Il modello è il cuore del sistema. Dovrebbe essere possibile svilupparlo e testarlo indipendentemente dall'interfaccia utente.
- Per raggiungere questo obiettivo, nella prima fase della divisione, è necessario suddividere il sistema in un modello e un'interfaccia utente.
- Quindi, utilizzando il pattern dell'osservatore, rafforziamo l'indipendenza del modello e sincronizziamo le interfacce utente.
- Il terzo passaggio consiste nel suddividere l'interfaccia utente in un controller e visualizzare.
- Tutto ciò che è necessario per ricevere i dati dell'utente nel sistema si trova nel controller.
- Tutto ciò che è necessario per fornire informazioni all'utente è nella vista.
Un po' su come la vista e il controller interagiscono con il modello
Inserendo le informazioni tramite il controller, l'utente cambia il modello. O almeno, l'utente modifica i dati del modello. Quando l'utente riceve informazioni tramite gli elementi dell'interfaccia (tramite la vista), l'utente riceve informazioni sul modello. Come succede? In che modo la vista e il controller interagiscono con il modello? Dopotutto, le classi della vista non possono chiamare direttamente i metodi delle classi del modello per leggere/scrivere dati. Altrimenti non potremmo dire che il modello è indipendente. Il modello è un insieme di classi strettamente correlate a cui né la vista né il controller dovrebbero avere accesso. Per connettere il modello alla vista e al controller, dobbiamo implementare il modello di progettazione della facciata. La facciata del modello è lo strato tra il modello e l'interfaccia utente, attraverso il quale la vista riceve dati opportunamente formattati e il Controller modifica i dati chiamando i metodi necessari sulla facciata. Alla fine, tutto sembra così:
GO TO FULL VERSION