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.
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
Dichiarazione di non responsabilità: MVC non è un modello di progettazione. MVC è un insieme di idee e principi architettonici per la creazione di sistemi complessi con un'interfaccia utente. Ma per comodità, per non ripetere ripetutamente "un insieme di idee architettoniche...", faremo riferimento al pattern MVC. Iniziamo con il semplice. Cosa si nasconde dietro le parole Model-View-Controller? Quando si utilizza il modello MVC per sviluppare sistemi con un'interfaccia utente, è necessario suddividere il sistema in tre componenti. Possono anche essere chiamati moduli o componenti. Chiamali come vuoi, ma dividi il sistema in tre componenti. Ogni componente ha il suo scopo. Modello. Il primo componente/modulo è chiamato modello. Contiene tutta la logica di business dell'applicazione. Visualizzazione.La seconda parte del sistema è la vista. Questo modulo è responsabile della visualizzazione dei dati all'utente. Tutto ciò che l'utente vede è generato dalla vista. Controllore.Il terzo anello di questa catena è il controllore. Contiene il codice responsabile della gestione delle azioni dell'utente (tutte le azioni dell'utente sono gestite nel controller). Il modello è la parte più indipendente del sistema. Così indipendente che non deve sapere nulla dei moduli view e controller. Il modello è così indipendente che i suoi sviluppatori potrebbero non sapere praticamente nulla della vista e del controller. Lo scopo principale della vista è fornire informazioni dal modello in un formato che l'utente possa utilizzare. Il limite principale della vista è che non deve modificare in alcun modo il modello. Lo scopo principale del controller è gestire le azioni dell'utente. È attraverso il controller che l'utente apporta modifiche al modello. O più precisamente, ai dati memorizzati nel modello. Ecco il diagramma che hai visto in precedenza nella lezione: Da tutto ciò, possiamo trarre una conclusione logica. Un sistema complesso deve essere suddiviso in moduli. Descriviamo brevemente i passaggi per ottenere questa separazione.
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
L'esempio seguente ti aiuterà a capire cosa intendiamo per sincronizzazione delle interfacce utente. Supponiamo di acquistare online un biglietto per il cinema e di vedere il numero di posti disponibili in sala. Allo stesso tempo, qualcun altro potrebbe acquistare un biglietto per il cinema. Se quest'altra persona acquista un biglietto prima di noi, vorremmo vedere una diminuzione del numero di posti disponibili per lo spettacolo che stiamo considerando. Ora pensiamo a come questo può essere implementato all'interno di un programma. Supponiamo di avere il nucleo del nostro sistema (il nostro modello) e l'interfaccia (la pagina web per l'acquisto dei biglietti). Due utenti cercano contemporaneamente di scegliere un posto a teatro. Il primo utente acquista un biglietto. La pagina Web deve mostrare al secondo utente che ciò è accaduto. Come dovrebbe accadere? Se aggiorniamo l'interfaccia dal core, quindi il core (il nostro modello) dipenderà dall'interfaccia. Mentre sviluppiamo e testiamo il modello, dovremo tenere a mente i vari modi di aggiornare l'interfaccia. Per raggiungere questo obiettivo, dobbiamo implementare il modello dell'osservatore. Questo modello consente al modello di inviare notifiche di modifica a tutti i listener. In qualità di listener di eventi (o osservatore), l'interfaccia utente riceve le notifiche e viene aggiornata. Da un lato, il modello dell'osservatore consente al modello di informare l'interfaccia (vista e controllore) che sono avvenuti cambiamenti senza che ne sappia effettivamente nulla, rimanendo così indipendente. D'altra parte, consente di sincronizzare le interfacce utente. dobbiamo implementare il modello dell'osservatore. Questo modello consente al modello di inviare notifiche di modifica a tutti i listener. In qualità di listener di eventi (o osservatore), l'interfaccia utente riceve le notifiche e viene aggiornata. Da un lato, il modello dell'osservatore consente al modello di informare l'interfaccia (vista e controllore) che sono avvenuti cambiamenti senza che ne sappia effettivamente nulla, rimanendo così indipendente. D'altra parte, consente di sincronizzare le interfacce utente. dobbiamo implementare il modello dell'osservatore. Questo modello consente al modello di inviare notifiche di modifica a tutti i listener. In qualità di listener di eventi (o osservatore), l'interfaccia utente riceve le notifiche e viene aggiornata. Da un lato, il modello dell'osservatore consente al modello di informare l'interfaccia (vista e controllore) che sono avvenuti cambiamenti senza che ne sappia effettivamente nulla, rimanendo così indipendente. D'altra parte, consente di 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)
Queste funzioni determinano come l'interfaccia utente deve essere suddivisa in moduli. Alla fine, l'architettura del sistema si presenta così: Ed è così che arriviamo a un'applicazione composta da tre moduli chiamati modello, vista e controller. Riassumiamo:
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.
Solo un'altra cosa importante da discutere prima di poter bere la tua cioccolata calda.
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ì:
MVC: Cosa ci guadagniamo?
L'obiettivo principale del paradigma MVC è separare l'implementazione della logica di business (il modello) dalla sua visualizzazione (la vista). Questa separazione aumenta le possibilità di riutilizzo del codice. I vantaggi di MVC sono più evidenti quando è necessario presentare gli stessi dati in formati diversi. Ad esempio, come tabella, grafico o grafico (utilizzando viste diverse). Allo stesso tempo, senza influire sul modo in cui vengono implementate le visualizzazioni, possiamo modificare il modo in cui rispondiamo alle azioni dell'utente (clic sui pulsanti, immissione dei dati). Se segui i principi di MVC, puoi semplificare lo sviluppo del software, aumentare la leggibilità del codice e migliorare l'estensibilità e la manutenibilità. Nell'articolo finale della serie "Introduzione allo sviluppo aziendale", esamineremo un'implementazione MVC creata utilizzando Spring MVC. Parte 8. Scriviamo una piccola applicazione usando Spring Boot
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:
