In questo materiale ti presenteremo qualcosa come MVC. Parliamo di cos'è MVC, tocchiamo la storia della sua creazione, comprendiamo le principali idee e concetti inerenti a MVC, consideriamo passo dopo passo come suddividere un'applicazione in moduli Modello, Vista, Controller e anche scrivere una piccola applicazione web in Spring-Boot e utilizzando Spring-MVC come esempio, vediamo come i dati vengono trasferiti dal codice Java alle pagine html. Per comprendere questo materiale, è necessario avere familiarità con i design pattern, in particolare Observer e Facade. Avere familiarità con le richieste e le risposte HTTP, comprendere le basi dell'HTML, sapere cosa sono le annotazioni in Java. Siediti, prepara il tè, prepara il dessert, l'insalata, la portata principale e il primo piatto. Noi iniziamo.
Storia di MVC
Le idee per MVC furono formulate da Trygve Reenskaug mentre lavorava allo Xerox PARC alla fine degli anni '70. A quei tempi, per lavorare con un computer era impossibile fare a meno di un titolo accademico e dello studio costante di voluminosa documentazione. Il problema che Reenskaug ha risolto insieme ad un gruppo di sviluppatori molto forti è stato quello di semplificare l'interazione dell'utente medio con un computer. Era necessario creare strumenti che, da un lato, fossero estremamente semplici e comprensibili e, dall'altro, consentissero di gestire un computer e applicazioni complesse. Reenskaug ha lavorato nel team che ha sviluppato il computer portatile "per bambini di tutte le età" - Dynabook, così come il linguaggio SmallTalk sotto la direzione di Alan Kay. Fu allora che furono stabiliti i concetti di un'interfaccia amichevole. Il lavoro di Reenskaug con il suo team ha influenzato notevolmente lo sviluppo del campo IT. Presentiamo un fatto interessante che non si riferisce direttamente a MVC, ma illustra il significato di tali sviluppi. Nel 2007, dopo la presentazione dell’iPhone di Apple, Alan Kay disse: “Quando è uscito il Macintosh, Newsweek mi ha chiesto cosa ne pensassi. Ho detto: questo è il primo personal computer degno di critica. Dopo la presentazione, Steve Jobs si è avvicinato e ha chiesto: l'iPhone è degno di critica? E ho detto, fallo cinque per otto pollici e conquisterai il mondo. Tre anni dopo, il 27 gennaio 2010, Apple ha introdotto l'iPad da 9,7 pollici. Cioè, Steve Jobs ha seguito quasi alla lettera il consiglio di Alan Kay. Il progetto su cui Rennskaug ha lavorato è durato 10 anni. E la prima pubblicazione su MVC da parte dei suoi creatori è stata pubblicata altri 10 anni dopo. Martin Fowler, autore di numerosi libri e articoli sull'architettura software, afferma di aver imparato MVC da una versione funzionante di SmallTalk. Poiché per molto tempo non sono state fornite informazioni su MVC dalla fonte primaria, nonché per una serie di altri motivi, sono apparse numerose interpretazioni diverse di questo concetto. Di conseguenza, molte persone considerano MVC uno schema o modello di progettazione. Meno comunemente, MVC è chiamato modello composito o una combinazione di diversi modelli che lavorano insieme per implementare applicazioni complesse. Ma in realtà, come detto prima, MVC è principalmente un insieme di idee/principi/approcci architettonici che possono essere implementati in vari modi utilizzando vari modelli... Successivamente, proveremo a esaminare le idee principali incorporate nel concetto MVC.
Cos'è 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 acronimo che sta per Model-View-Controller.
Dichiarazione di non responsabilità: MVC non è un modello di progettazione. MVC è precisamente un insieme di idee e principi architettonici per la costruzione di sistemi complessi con un'interfaccia utente. Ma per comodità, per non ripetere ogni volta: “Un insieme di idee architettoniche...”, chiameremo MVC pattern. Cominciamo con qualcosa di semplice. Cosa si nasconde dietro le parole Model-View-Controller? Quando si sviluppano sistemi con un'interfaccia utente, seguendo lo schema MVC, è necessario dividere il sistema in tre componenti. Questi, a loro volta, possono essere chiamati moduli o componenti. Dì quello che vuoi, ma dividi per tre. Ogni componente avrà il suo scopo. Modello. Il primo componente/modulo è il cosiddetto modello. Contiene tutta la logica aziendale dell'applicazione. Visualizzazione. La seconda parte del sistema è la vista. Questo modulo è responsabile della visualizzazione dei dati all'utente. Tutto ciò che vede l'utente è generato dalla vista. Controllore. Il terzo anello di questa catena è il titolare del trattamento. Memorizza il codice responsabile dell'elaborazione delle azioni dell'utente (qualsiasi azione dell'utente nel sistema viene elaborata nel controller). Il modello è la parte più indipendente del sistema. Così indipendente che non dovrebbe sapere nulla dei moduli View e Controller. Il modello è così indipendente che i suoi sviluppatori potrebbero non sapere praticamente nulla della View e del Controller. Lo scopo principale della View è fornire informazioni dal Modello in un formato user-friendly. Il limite principale della View è che non dovrebbe modificare in alcun modo il modello. Lo scopo principale del Titolare è elaborare le azioni dell'utente. È attraverso il Controller che l'utente apporta modifiche al modello. Più precisamente, nei dati memorizzati nel modello. Riportiamo il diagramma che vi è già stato mostrato durante la conferenza: da tutto ciò possiamo trarre una conclusione del tutto logica. Un sistema complesso necessita di essere suddiviso in moduli. Descriviamo brevemente i passaggi su come ottenere tale separazione.
Passaggio 1: separare la logica aziendale dell'applicazione dall'interfaccia utente
L'idea chiave di MVC è che qualsiasi applicazione dotata di interfaccia utente, in prima approssimazione, può essere divisa in 2 moduli: un modulo responsabile dell'implementazione della logica di business dell'applicazione e un'interfaccia utente. Il primo modulo implementerà le funzionalità principali dell'applicazione. Questo modulo costituirà il nucleo del sistema, in cui verrà implementato il modello del dominio applicativo. Nel concetto MVC, questo modulo sarà la nostra lettera M, cioè modello. Il secondo modulo implementerà l'intera interfaccia utente, inclusa la visualizzazione dei dati all'utente e la logica di interazione dell'utente con l'applicazione. Lo scopo principale di questa separazione è garantire che il nucleo del sistema (modello nella terminologia MVC) possa essere sviluppato e testato in modo indipendente. L'architettura dell'applicazione dopo tale divisione sarà simile alla seguente:
Passaggio 2. Utilizzando il modello Observer, ottieni un'indipendenza ancora maggiore del modello, nonché la sincronizzazione delle interfacce utente
Qui perseguiamo 2 obiettivi:
Ottieni un'indipendenza ancora maggiore dal modello.
Sincronizzare le interfacce utente.
L'esempio seguente ti aiuterà a capire cosa si intende per sincronizzazione delle interfacce utente. Diciamo che acquistiamo un biglietto del cinema online e vediamo il numero di posti disponibili nel cinema. Qualcun altro può acquistare un biglietto per il cinema contemporaneamente a noi. Se questo qualcuno acquista il biglietto prima di noi, vorremmo vedere che il numero di posti disponibili per la nostra sessione sia diminuito. Ora pensiamo a come questo può essere implementato all'interno del programma. Supponiamo di avere un nucleo del sistema (il nostro modello) e un'interfaccia (la pagina web su cui effettuiamo un acquisto). Sul sito, 2 utenti selezionano contemporaneamente un posto. Il primo utente ha acquistato un biglietto. Il secondo utente deve visualizzare queste informazioni sulla pagina. Come dovrebbe accadere? Se aggiorniamo l'interfaccia dal kernel di sistema, il nostro kernel, il nostro modello, dipenderà dall'interfaccia. Quando sviluppi e testi un modello, dovrai tenere a mente vari modi per aggiornare l'interfaccia. Per raggiungere questo obiettivo, è necessario implementare il modello Observer. Con il suo aiuto, il modello invia notifiche sulle modifiche a tutti gli abbonati. L'interfaccia, essendo tale abbonato, riceverà una notifica e un aggiornamento. Il modello Observer consente al modello, da un lato, di informare l'interfaccia (vista e controller) che in esso sono avvenuti dei cambiamenti e, dall'altro, di non "sapere" nulla al riguardo e quindi di rimanere indipendente. D'altra parte, ciò consentirà la sincronizzazione delle interfacce utente.
Passaggio 3. Dividere l'interfaccia in View e Controller
Continuiamo a dividere l'applicazione in moduli, ma ad un livello inferiore della gerarchia. In questo passaggio l'interfaccia utente (che nel passaggio 1 era separata in un modulo separato) è divisa in una vista e un controller. È difficile tracciare una linea netta tra una vista e un controller. Se diciamo che la vista è ciò che vede l’utente, e il controllore è il meccanismo attraverso il quale l’utente può interagire con il sistema, c’è qualche contraddizione. I controlli, come i pulsanti su una pagina Web o una tastiera virtuale sullo schermo del telefono, fanno essenzialmente parte di un controller. Ma sono visibili all'utente quanto qualsiasi parte della vista. Qui stiamo parlando più di divisione funzionale. Il compito principale dell'interfaccia utente è garantire l'interazione dell'utente con il sistema. Ciò significa che l'interfaccia ha solo 2 funzioni:
visualizzare e visualizzare comodamente le informazioni sul sistema all'utente;
inserire i dati e i comandi dell'utente nel sistema (trasmetterli al sistema);
Queste funzioni determinano come l'interfaccia deve essere divisa in moduli. Di conseguenza, l'architettura del sistema è simile a questa: Quindi, abbiamo un'applicazione di tre moduli chiamati Model, View e Controller. Riassumere:
Seguendo i principi di MVC, il sistema deve essere suddiviso in moduli.
Il modulo più importante e indipendente dovrebbe essere il modello.
Il modello è il cuore del sistema. È necessaria la capacità di svilupparlo e testarlo indipendentemente dall'interfaccia.
Per fare ciò, nella prima fase della segregazione del sistema, è necessario dividerlo in un modello e un'interfaccia.
Successivamente, utilizzando il pattern Observer, rafforziamo il modello nella sua indipendenza e otteniamo la sincronizzazione delle interfacce utente.
Il terzo passaggio consiste nel dividere l'interfaccia in un controller e una vista.
Tutto ciò che è necessario per inserire le informazioni dell'utente nel sistema è nel controller.
Tutto ciò che trasmette informazioni dal sistema all'utente è in vista.
C'è ancora una cosa importante da discutere e puoi bere il cacao.
Un po' sulla relazione tra la View, il Controller e il Model
Quando l'utente inserisce le informazioni tramite il controller, apporta modifiche al modello. Almeno l'utente apporta modifiche ai dati del modello. Quando l'utente riceve informazioni tramite elementi dell'interfaccia (tramite la vista), l'utente riceve informazioni sui dati del modello. Come avviene questo? Come interagiscono la vista e il controller con il modello? Dopotutto non può essere che le classi View utilizzino direttamente i metodi delle classi Model per leggere/scrivere dati, altrimenti non si può parlare di indipendenza del Model. Il Modello rappresenta un insieme di classi strettamente interconnesse a cui, in buona fede, né la View né il Controller dovrebbero avere accesso. Per connettere il Modello con la Vista e il Controller, è necessario implementare il modello di progettazione della Facciata. La facciata del modello sarà lo strato stesso tra il modello e l'interfaccia, attraverso il quale la vista riceve i dati in un formato conveniente e il controller modifica i dati chiamando i metodi di facciata necessari. Schematicamente, alla fine, tutto sarà simile a questo:
MVC: qual è il vantaggio?
L'obiettivo principale del rispetto dei principi MVC è separare l'implementazione della logica aziendale (modello) dell'applicazione dalla sua visualizzazione (vista). Questa separazione aumenterà il riutilizzo del codice. I vantaggi dell'utilizzo di MVC sono più evidenti nei casi in cui l'utente deve fornire gli stessi dati in formati diversi. Ad esempio, sotto forma di tabella, grafico o diagramma (utilizzando diversi tipi). Allo stesso tempo, senza influire sull'implementazione delle visualizzazioni, è possibile modificare le reazioni alle azioni dell'utente (fare clic su un pulsante, inserire dati). Se segui i principi di MVC, puoi semplificare la scrittura dei programmi, aumentare la leggibilità del codice e rendere più semplice l'espansione e la manutenzione del sistema in futuro. Nel materiale finale della serie "Introduzione allo sviluppo aziendale", esamineremo l'implementazione di MVC utilizzando Spring-MVC come esempio. Parte 8. Scrivere una piccola applicazione in spring-boot
da tutto ciò possiamo trarre una conclusione del tutto logica. Un sistema complesso necessita di essere suddiviso in moduli. Descriviamo brevemente i passaggi su come ottenere tale separazione.
Quindi, abbiamo un'applicazione di tre moduli chiamati Model, View e Controller. Riassumere:
GO TO FULL VERSION