Introduzione all'architettura MVC
L'architettura dell'applicazione più popolare che ogni programmatore conosce è MVC . MVC è l'acronimo di Model-View-Controller .
Questa non è tanto l'architettura delle applicazioni quanto l'architettura dei componenti dell'applicazione, ma torneremo su questa sfumatura più avanti. Cos'è MVC?
MVC è uno schema per separare i dati dell'applicazione e la logica di controllo in tre componenti separati: modello, vista e controller , in modo che ogni componente possa essere modificato in modo indipendente.
- Model (Model) fornisce dati e risponde ai comandi del controller modificandone lo stato.
- La vista è responsabile della visualizzazione dei dati del modello all'utente in risposta alle modifiche del modello.
- Il Titolare (Controller) interpreta le azioni dell'utente, notificando al modello la necessità di modifiche.
Questo modello è stato inventato nel 1978 (!) Anno. Sì, i problemi con un'architettura software adeguata erano rilevanti 50 anni fa. Ecco come questo modello è descritto dal diagramma nell'originale:
Il modello fornisce dati e metodi per lavorare con essi: interrogazioni al database, verifica della correttezza. Il modello è indipendente dalla vista (non sa come visualizzare i dati) e dal controller (non ha punti di interazione con l'utente), fornendo accesso e gestione dei dati.
Il modello è costruito in modo tale da rispondere alle richieste modificandone lo stato e può essere incorporata la notifica degli "osservatori". Il modello, a causa dell'indipendenza dalla rappresentazione visiva, può avere diverse rappresentazioni per un "modello".
La vista è responsabile di ottenere i dati richiesti dal modello e di inviarli all'utente. La vista non elabora l'input dell'utente.
Il controller fornisce la "comunicazione" tra l'utente e il sistema. Controlla e indirizza i dati dall'utente al sistema e viceversa. Utilizza un modello e una vista per implementare l'azione desiderata.
C'è una certa difficoltà con il fatto che questo modello si è evoluto un po' nel corso dei decenni. Cioè, il nome è rimasto lo stesso, ma lo scopo delle parti ha cominciato a cambiare.
Architettura MVC sul web
L'idea alla base del modello di progettazione MVC è molto semplice: dobbiamo separare chiaramente la responsabilità dei diversi comportamenti nelle nostre applicazioni:
Modello— elaborazione dati e logica applicativa.
visualizzazione— fornire dati all'utente in qualsiasi formato supportato.
controllore- elaborare le richieste degli utenti e chiamare le risorse appropriate.
L'applicazione è suddivisa in tre componenti principali, ognuno dei quali è responsabile di compiti diversi. Diamo un'occhiata più da vicino ai componenti di un'applicazione client-server utilizzando un esempio.
Controllore
L'utente fa clic su vari elementi della pagina nel browser, a seguito dei quali il browser invia varie richieste HTTP: GET, POST o altre. Il controller può includere il browser e il codice JS che funzionano all'interno della pagina.
La funzione principale del controller in questo caso è chiamare metodi sugli oggetti necessari, gestire l'accesso alle risorse per eseguire attività specificate dall'utente. In genere, il controller richiama il modello appropriato per l'attività e seleziona la visualizzazione appropriata.
Modello
Il modello in senso lato è costituito dai dati e dalle regole utilizzati per lavorare con i dati: insieme costituiscono la logica aziendale dell'applicazione. La progettazione di un'applicazione inizia sempre con la creazione di modelli degli oggetti su cui opera.
Diciamo che abbiamo un negozio online che vende libri, quindi una persona è solo un utente dell'applicazione o anche un autore di un libro? Queste importanti domande devono essere affrontate durante la progettazione del modello.
Inoltre ci sono serie di regole: cosa si può fare, cosa non si può fare, quali set di dati sono accettabili e quali no. Può esistere un libro senza un autore? E l'autore senza libri? La data di nascita dell'utente può essere nell'anno 300 e così via.
Il modello fornisce al titolare una visione dei dati che l'utente ha richiesto (messaggio, pagina del libro, immagini, ecc.). Il modello di dati sarà lo stesso indipendentemente da come vogliamo presentarlo all'utente. Pertanto, scegliamo qualsiasi visualizzazione disponibile per visualizzare i dati.
Il modello contiene la parte più importante della nostra logica applicativa , la logica che risolve il problema che stiamo affrontando (forum, negozio, banca, ecc.). Il controller contiene principalmente la logica organizzativa per l'applicazione stessa (proprio come il tuo Project Manager).
Visualizzazione
La vista offre vari modi per rappresentare i dati ricevuti dal modello. Può essere un modello pieno di dati. Possono esserci diverse visualizzazioni e il controller sceglie quale è la migliore per la situazione attuale.
Un'applicazione Web è generalmente costituita da un insieme di controller, modelli e viste. Il controller può trovarsi solo sul backend, ma può esserci anche una variante di più controller, quando la sua logica è distribuita anche sul frontend. Un buon esempio di questo approccio è qualsiasi applicazione mobile.
Esempio MVC sul web
Supponiamo che tu debba sviluppare un negozio online che venderà libri. L'utente può eseguire le seguenti azioni: visualizzare i libri, registrarsi, acquistare, aggiungere articoli all'ordine corrente, contrassegnare i libri che gli piacciono e acquistarli.
La tua applicazione dovrebbe avere un modello responsabile di tutta la logica aziendale. È inoltre necessario un controller che elaborerà tutte le azioni dell'utente e le trasformerà in chiamate di metodo dalla logica aziendale. Tuttavia, un metodo del controller può chiamare molti metodi del modello diversi.
Hai anche bisogno di set di visualizzazioni: un elenco di libri, informazioni su un libro, un carrello della spesa, un elenco di ordini. Ogni pagina di un'applicazione Web è in realtà una vista separata che mostra all'utente un determinato aspetto del modello.
Vediamo cosa succede se un utente apre un elenco di libri consigliati dalla libreria per visualizzare i titoli. L'intera sequenza di azioni può essere descritta sotto forma di 6 passaggi:
Passi:
- L'utente fa clic sul collegamento "consigliato" e il browser invia una richiesta , ad esempio, a /books/recommendations.
- Il titolare verifica la richiesta : l'utente deve essere loggato. Oppure dovremmo avere raccolte di libri per gli utenti non registrati. Il titolare chiama quindi la modella e le chiede di restituire l'elenco dei libri consigliati all'utente N.
- Il modello accede al database, recupera le informazioni sui libri da lì: libri che sono attualmente popolari, libri acquistati dall'utente, libri acquistati dai suoi amici, libri dalla sua lista dei desideri. Sulla base di questi dati, il modello crea un elenco di 10 libri consigliati e li restituisce al controllore.
- Il controller riceve un elenco di libri consigliati e lo esamina. In questa fase, il controllore prende le decisioni! Se ci sono pochi libri o l'elenco è completamente vuoto, richiede un elenco di libri per un utente non registrato. Se c'è una promozione in corso in questo momento, il controller può aggiungere libri promozionali all'elenco.
- Il controller determina quale pagina mostrare all'utente. Può essere una pagina di errore, una pagina con un elenco di libri, una pagina di congratulazioni per il fatto che l'utente è diventato un milionesimo visitatore.
- Il server fornisce al client la pagina ( view ) selezionata dal controller. Viene riempito con i dati necessari (nome utente, elenco di libri) e va al cliente.
- Il client riceve la pagina e la mostra all'utente.
Quali sono i vantaggi di questo approccio?
Il vantaggio più ovvio che otteniamo dall'utilizzo del concetto MVC è una netta separazione tra logica di presentazione (interfaccia utente) e logica applicativa (backend).
Il secondo vantaggio è la divisione della parte server in due: un modello smart ( executor ) e un controller ( decision center ).
Nell'esempio precedente, c'è stato un momento in cui il controller poteva ricevere un elenco vuoto di libri consigliati dal modello e decidere cosa farne. Teoricamente, questa logica potrebbe essere inserita direttamente nel modello.
Innanzitutto, quando richiede i libri consigliati, il modello decide cosa fare se l'elenco è vuoto. Quindi dovrei aggiungere il codice nello stesso posto, cosa fare se c'è una promozione in corso ora, quindi opzioni più diverse.
Quindi si è scoperto che l'amministratore del negozio voleva vedere come sarebbe stata la pagina dell'utente senza promozione, o viceversa, non c'è promozione ora, ma vuole vedere come verrà visualizzata la promozione futura. E non ci sono metodi per questo. Pertanto, si è deciso di separare il centro decisionale (controllore) dalla logica aziendale (modello).
Oltre a isolare le viste dalla logica dell'applicazione, il concetto MVC riduce notevolmente la complessità delle applicazioni di grandi dimensioni. Il codice è molto più strutturato, semplificando la manutenzione, il test e il riutilizzo delle soluzioni.
Comprendendo il concetto di MVC, tu, come sviluppatore, ti rendi conto di dove è necessario aggiungere l'ordinamento all'elenco dei libri:
- A livello di query del database.
- A livello di business logic (modello).
- A livello di logica aziendale (controllore).
- Nella vista - sul lato client.
E questa non è una domanda retorica. In questo momento, pensa a dove e perché devi aggiungere il codice per ordinare l'elenco dei libri.
Modello MVC classico
L'interazione tra i componenti MVC è implementata in modo diverso nelle applicazioni Web e nelle applicazioni mobili. Questo perché l'app Web è di breve durata, elabora una richiesta utente ed esce, mentre l'app mobile elabora molte richieste senza riavviarsi.
Le applicazioni Web in genere utilizzano il modello "passivo", mentre le applicazioni mobili utilizzano il modello "attivo". Il modello attivo, a differenza di quello passivo, ti consente di iscriverti e ricevere notifiche di modifiche in esso. Questo non è richiesto per le applicazioni web.
Ecco come appare l'interazione dei componenti in vari modelli:
Le applicazioni mobili (modello attivo) utilizzano attivamente gli eventi e il meccanismo di sottoscrizione degli eventi. Con questo approccio, view ( view ) sottoscrive le modifiche al modello. Quindi, quando si verifica un evento (ad esempio, l'utente fa clic su un pulsante), viene chiamato il controller . Fornisce inoltre al modello un comando per modificare i dati.
Se alcuni dati sono cambiati, il modello genera un evento sulla modifica di questi dati. Tutte le viste che si sono iscritte a questo evento (per le quali è importante modificare questi dati particolari) ricevono questo evento e aggiornano i dati nella loro interfaccia.
Nelle applicazioni web, le cose sono organizzate in modo leggermente diverso. La principale differenza tecnica è che il client non può ricevere messaggi lato server su iniziativa del server .
Pertanto, un controller in un'applicazione Web di solito non invia alcun messaggio alla vista, ma fornisce al client una nuova pagina, che tecnicamente è una nuova vista o anche una nuova applicazione client (se una pagina non sa nulla dell'altra) .
Allo stato attuale, questo problema è parzialmente risolto utilizzando i seguenti approcci:
- Interrogare regolarmente il server per le modifiche ai dati importanti (una volta al minuto o più).
- I WebSocket consentono a un client di sottoscrivere i messaggi del server.
- Notifiche push Web dal lato server.
- Il protocollo HTTP/2 consente al server di avviare l'invio di messaggi al client.
GO TO FULL VERSION