Cos'è MVC, davvero?

Come programmatore serio, come rispondi alla domanda Che cos'è MVC?

Nella mia mente, MVC è una specie di argomento nebuloso - e per questo, se il tuo pubblico è uno studente, allora sei libero di descriverlo in termini generali che difficilmente saranno controversi.

Tuttavia, se stai parlando con un pubblico esperto, in particolare un intervistatore, faccio fatica a pensare a una direzione da prendere che non rischia una reazione di "beh, non è giusto! ...". Abbiamo tutti un'esperienza diversa nel mondo reale e non ho mai incontrato due volte lo stesso modello di implementazione MVC.

In particolare, sembrano esserci disaccordi in merito a rigidità, definizione dei componenti, separazione delle parti (quale pezzo si adatta dove), ecc.

Quindi, come dovrei spiegare MVC in modo corretto, conciso e non controverso?

MVC è un'architettura software - la struttura del sistema - che separa la logica di dominio / applicazione / business (qualunque cosa preferiate) dal resto dell'interfaccia utente. Lo fa separando l'applicazione in tre parti: il modello, la vista e il controller.

Il modello gestisce comportamenti e dati fondamentali dell'applicazione. Può rispondere alle richieste di informazioni, rispondere alle istruzioni per modificare lo stato delle informazioni e persino informare gli osservatori nei sistemi guidati dagli eventi quando le informazioni cambiano. Potrebbe trattarsi di un database o di un numero qualsiasi di strutture dati o sistemi di archiviazione. In breve, sono i dati e la gestione dei dati dell'applicazione.

La vista fornisce effettivamente l'elemento dell'interfaccia utente dell'applicazione. Trasformerà i dati dal modello in un modulo adatto all'interfaccia utente.

Il controller riceve l'input dell'utente ed effettua chiamate per modellare oggetti e la vista per eseguire azioni appropriate.

Tutto sommato, questi tre componenti lavorano insieme per creare i tre componenti di base di MVC.

Analogia

Ho spiegato MVC a mio padre in questo modo:

MVC (Model, View, Controller) è un modello per l'organizzazione del codice in un'applicazione per migliorare la manutenibilità.

Immagina un fotografo con la sua macchina fotografica in uno studio. Un cliente gli chiede di scattare una foto di una scatola.

La scatola è il modello , il fotografo è il controller e la fotocamera è la vista .

Poiché la scatola non è a conoscenza della fotocamera o del fotografo, è completamente indipendente. Questa separazione consente al fotografo di girare intorno alla scatola e puntare la fotocamera in qualsiasi angolazione per ottenere lo scatto / vista che desidera.

Le architetture non MVC tendono ad essere strettamente integrate insieme. Se la scatola, il controller e la videocamera fossero lo stesso oggetto, allora dovremmo separarci e ricostruire sia la scatola che la videocamera ogni volta che desideriamo ottenere una nuova vista. Inoltre, scattare la foto sarebbe sempre come provare a fare un selfie - e non è sempre molto facile.

Spiegazione dettagliata

Fu solo dopo aver letto la seguente domanda / risposta da maillista che mi sentii come se avessi capito MVC. Citazione: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha ha scritto:

L'autore fa riferimento a mvctree.py in wxPython come esempio di progettazione MVC. Comunque sono ancora troppo verde quindi trovo quell'esempio particolare troppo complesso e non capisco la separazione che l'autore sta raccomandando.

MVC è tutto sulla separazione delle preoccupazioni.

Il modello è responsabile della gestione dei dati del programma (sia privati ​​che client). Il View / Controller è responsabile di fornire al mondo esterno i mezzi per interagire con i dati del client del programma.

Il modello fornisce un'interfaccia interna (API) per consentire ad altre parti del programma di interagire con esso. View / Controller fornisce un'interfaccia esterna (GUI / CLI / modulo web / IPC di alto livello / ecc.) Per consentire a tutto ciò che è estraneo al programma di comunicare con esso.

Il Modello è responsabile del mantenimento dell'integrità dei dati del programma, perché se viene danneggiato, il gioco è finito per tutti. Il View / Controller è responsabile del mantenimento dell'integrità dell'interfaccia utente, assicurandosi che tutte le visualizzazioni di testo visualizzino valori aggiornati, disabilitando le voci di menu che non si applicano al focus corrente, ecc.

Il modello non contiene alcun codice View / Controller; nessuna classe di widget GUI, nessun codice per la disposizione di finestre di dialogo o la ricezione di input da parte dell'utente. La vista / controller non contiene alcun codice modello; nessun codice per la convalida degli URL o l'esecuzione di query SQL e nessuno stato originale: tutti i dati detenuti dai widget sono solo a scopo di visualizzazione e sono semplicemente un riflesso dei dati reali memorizzati nel modello.

Ora, ecco il test di un vero design MVC: il programma dovrebbe in sostanza essere perfettamente funzionante anche senza un View / Controller collegato. OK, il mondo esterno avrà difficoltà ad interagire con esso in quella forma, ma fino a quando si conoscono gli incantesimi API modello appropriati, il programma manterrà e manipolerà i dati normalmente.

Perché è possibile? Bene, la semplice risposta è che è tutto grazie al basso accoppiamento tra i livelli Model e View / Controller. Tuttavia, questa non è la storia completa. La chiave di tutto il modello MVC è la direzione in cui va quella connessione: TUTTE le istruzioni scorrono dalla vista / controller al modello. Il modello MAI dice al View / Controller cosa fare.

Perché? Perché in MVC, mentre al View / Controller è permesso conoscere un po 'del Modello (in particolare, l'API del Modello), ma al Modello non è permesso sapere nulla del View / Controller.

Perché? Perché MVC riguarda la creazione di una chiara separazione delle preoccupazioni.

Perché? Per aiutare a prevenire la complessità del programma che sfugge al controllo e seppellisce te, lo sviluppatore, sotto di esso. Maggiore è il programma, maggiore è il numero di componenti in quel programma. E più connessioni esistono tra questi componenti, più è difficile per gli sviluppatori mantenere / estendere / sostituire i singoli componenti o anche semplicemente seguire il funzionamento dell'intero sistema. Chiediti questo: guardando un diagramma della struttura del programma, preferiresti vedere un albero o la culla di un gatto? Il modello MVC evita quest'ultimo impedendo le connessioni circolari: B può connettersi ad A, ma A non può connettersi a B. In questo caso, A è il modello e B è il View / Controller.

A proposito, se sei acuto, noterai un problema con la restrizione "unidirezionale" appena descritta: come può il Modello informare il View / Controller dei cambiamenti nei dati dell'utente del Modello quando il Modello non è nemmeno autorizzato a sai che il View / Controller, non importa inviare messaggi ad esso? Ma non preoccuparti: esiste una soluzione a questo, ed è piuttosto pulito anche se all'inizio sembra un po 'rotonda. Torneremo su questo tra un momento.

In termini pratici, quindi, un oggetto View / Controller può, tramite l'API del Modello, 1. dire al Modello di fare cose (eseguire comandi) e 2. dire al Modello di dargli cose (restituire dati). Il livello Visualizza / Controller invia le istruzioni al livello Modello e estrae informazioni dal livello Modello.

Ed è qui che il tuo primo esempio di MyCoolListControl va storto, perché l'API per quella classe richiede che le informazioni vengano inserite al suo interno, quindi sei tornato ad avere un accoppiamento a due vie tra i livelli, violando le regole MVC e scaricandoti di nuovo nel l'architettura della culla di gatto che stavi [presumibilmente] cercando di evitare in primo luogo.

Invece, la classe MyCoolListControl dovrebbe andare con il flusso, estraendo i dati di cui ha bisogno dal livello sottostante, quando ne ha bisogno. Nel caso di un widget elenco, ciò significa generalmente chiedere quanti valori ci sono e quindi chiedere ciascuno di questi elementi a turno, perché si tratta del modo più semplice e più lento di farlo e quindi riduce al minimo il tipo di accoppiamento. E se il widget vuole, per esempio, presentare questi valori all'utente in un piacevole ordine alfabetico, allora è perogativo; e la sua responsabilità, ovviamente.

Ora, un ultimo enigma, come ho accennato in precedenza: come mantenere sincronizzato il display dell'interfaccia utente con lo stato del modello in un sistema basato su MVC?

Ecco il problema: molti oggetti View sono statiful, ad esempio una casella di controllo può essere spuntata o deselezionata, un campo di testo può contenere del testo modificabile. Tuttavia, MVC impone che tutti i dati utente vengano archiviati nel livello Modello, quindi tutti i dati conservati da altri livelli a scopo di visualizzazione (lo stato della casella di controllo, il testo corrente del campo di testo) devono quindi essere una copia sussidiaria di tali dati Modello principali. Ma se lo stato del modello cambia, la copia della vista di quello stato non sarà più accurata e dovrà essere aggiornata.

Ma come? Il modello MVC impedisce al modello di inviare una nuova copia di tali informazioni nel livello Visualizza. Diamine, non consente nemmeno al Modello di inviare a Visualizza un messaggio per dire che il suo stato è cambiato.

Be 'quasi. Va bene, al layer Model non è consentito parlare direttamente con altri layer, poiché per farlo sarebbe necessario sapere qualcosa su quei layer e le regole MVC lo impediscono. Tuttavia, se un albero cade in una foresta e nessuno è in giro per ascoltarlo, emette un suono?

La risposta, vedi, è quella di creare un sistema di notifiche, fornendo al livello Modello un posto in cui non può annunciare a nessuno in particolare che abbia appena fatto qualcosa di interessante. Altri layer possono quindi pubblicare gli ascoltatori con quel sistema di notifica per ascoltare gli annunci a cui sono effettivamente interessati. Il layer Model non ha bisogno di sapere nulla su chi sta ascoltando (o anche se qualcuno sta ascoltando!); pubblica solo un annuncio e poi se ne dimentica. E se qualcuno ascolta quell'annuncio e ha voglia di fare qualcosa in seguito - come chiedere al Modello alcuni nuovi dati in modo che possa aggiornare il suo display su schermo - allora fantastico. Il modello elenca solo le notifiche che invia come parte della sua definizione API; e ciò che chiunque altro fa con quella conoscenza dipende da loro.

MVC è preservato e tutti sono felici. Il framework delle applicazioni potrebbe anche fornire un sistema di notifiche integrato, oppure puoi scrivere il tuo in caso contrario (vedi il "modello di osservatore").

...

Comunque, spero che ti aiuti. Una volta comprese le motivazioni alla base di MVC, le ragioni per cui le cose vengono fatte in questo modo iniziano a dare un senso, anche quando - a prima vista - sembrano più complesse del necessario.

Saluti,

ha

MVC è principalmente una parola d'ordine.

Era considerato un modello, ma la sua definizione originale del 1979 è stata offuscata, tramandata, interpretata erroneamente, estratta dal contesto originale. È stato ridefinito al punto da iniziare a somigliare a una religione, e mentre questo certamente aiuta i suoi cultisti del carico a difenderla, il suo nome non si associa più a una solida serie di linee guida . Pertanto, non può più essere considerato un modello.

MVC non ha mai avuto lo scopo di descrivere le applicazioni web.
Né sistemi operativi moderni, né lingue.
(alcuni dei quali hanno effettivamente reso superflua la definizione del 1979)

È stato fatto per. E non ha funzionato.

Ora abbiamo a che fare con un osceno ibrido web-mvc che, con il suo terribile stato di parola d'ordine, la definizione sfavorevole e con programmatori semi-analfabeti come target demografico, rende una cattiva pubblicità ai modelli software in generale.

MVC, quindi, è diventata la separazione delle preoccupazioni distillate per le persone che non vogliono davvero pensarci troppo.

• Il modello di dati viene gestito in un modo,
• la vista in un altro,
• il resto è appena chiamato "controller" e lasciato alla discrezione del lettore.

I siti web / le applicazioni web negli anni '90 non erano utilizzati per applicare la separazione delle preoccupazioni.

Erano orribili pasticci di codice di spaghetti mescolati.
Modifiche all'interfaccia utente, riprogettazioni e riordini dei dati erano incredibilmente difficili, costosi, lunghi, deprimenti, sfortunati.

Le tecnologie Web come ASP, JSP e PHP rendono troppo facile mescolare la visualizzazione dei problemi con i dati e quelli delle applicazioni. I nuovi arrivati ​​sul campo di solito emettono codici inestricabili come in quei vecchi tempi.

Pertanto, un numero crescente di persone ha iniziato a ripetere "usa MVC" in loop infiniti nei forum di supporto. Il numero di persone si espanse al punto da includere manager e marketer (ad alcuni il termine era già familiare, da quei tempi nella programmazione della gui, in cui il modello aveva senso) e che divenne il colosso di una parola d'ordine che dobbiamo affrontare ora .

Allo stato attuale è buon senso , non una metodologia .
È un punto di partenza , non una soluzione .
È come dire alle persone di respirare aria o fare scricchiolii , non una cura per il cancro .

Il modo migliore per definirlo è andare agli scritti originali di Trygve Reenskaug , che l'ha inventato: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Questo documento, in particolare, è generalmente considerato il testo definitivo: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELLI

I modelli rappresentano la conoscenza. Un modello potrebbe essere un singolo oggetto (piuttosto poco interessante) o potrebbe essere una struttura di oggetti ...

Dovrebbe esserci una corrispondenza uno-a-uno tra il modello e le sue parti da un lato, e il mondo rappresentato come percepito dal proprietario del modello dall'altro. I nodi di un modello dovrebbero quindi rappresentare una parte identificabile del problema.

I nodi di un modello dovrebbero essere tutti sullo stesso livello di problema, è confuso e considerato forma sbagliata mescolare nodi orientati al problema (ad es. Appuntamenti del calendario) con dettagli di implementazione (ad es. Paragrafi).

VISUALIZZAZIONI

Una vista è una rappresentazione (visiva) del suo modello. Normalmente evidenzierebbe alcuni attributi del modello e ne sopprimerebbe altri. Funziona quindi come filtro di presentazione .

Una vista è allegata al suo modello (o parte del modello) e ottiene i dati necessari per la presentazione dal modello ponendo domande. Può anche aggiornare il modello inviando messaggi appropriati. Tutte queste domande e messaggi devono essere nella terminologia del modello, la vista dovrà quindi conoscere la semantica degli attributi del modello che rappresenta. (Ad esempio, può richiedere l'identificatore del modello e aspettarsi un'istanza di Text, non può presumere che il modello sia di classe Text.)

CONTROLLORI

Un controller è il collegamento tra un utente e il sistema. Fornisce all'utente l'input organizzando la visualizzazione delle viste pertinenti per presentarsi in posizioni appropriate sullo schermo. Fornisce mezzi per l'output dell'utente presentando all'utente menu o altri mezzi per fornire comandi e dati. Il controller riceve tale output dell'utente, lo traduce nei messaggi appropriati e li trasmette su una o più visualizzazioni.

Un controller non dovrebbe mai integrare le viste, ad esempio non dovrebbe mai collegare le viste dei nodi disegnando frecce tra di loro.

Al contrario, una vista non dovrebbe mai conoscere l'input dell'utente, come le operazioni del mouse e la pressione dei tasti. Dovrebbe essere sempre possibile scrivere un metodo in un controller che invia messaggi a viste che riproducono esattamente qualsiasi sequenza di comandi utente.

EDITORI

Un controller è collegato a tutte le sue viste, sono chiamate parti del controller. Alcune viste forniscono un controller speciale, un editor , che consente all'utente di modificare le informazioni presentate dalla vista. Tali editor possono essere collegati nel percorso tra il controller e la sua vista e fungeranno da estensione del controller. Una volta completato il processo di modifica, l'editor viene rimosso dal percorso e scartato.

Si noti che un editor comunica con l'utente attraverso le metafore della vista connessa, quindi l'editor è strettamente associato alla vista. Un controller si impadronirà di un editor chiedendone la visualizzazione: non esiste altra fonte appropriata.

MVC è un modello di progettazione utilizzato per isolare la logica aziendale dalla presentazione.

Si differenzia da molti altri modelli di progettazione per il fatto che di solito non è implementato in modo succinto, ma è la base di un framework.

Mentre un'applicazione che implementa un modello di strategia è solo un piccolo dettaglio a riguardo, affermare che un'app Web utilizza il modello di progettazione MVC sta definendo molto la sua architettura .

MVC è una progettazione software che separa i seguenti componenti di un sistema o sottosistema:

1. Modello: dati sullo stato dell'applicazione o dei suoi componenti. Può includere routine di modifica o accesso.
2. Visualizza - Un'interpretazione dei dati (modello). Questo è limitato solo a una rappresentazione visiva, ma potrebbe essere audio, informazioni derivate (ad es. Statistiche convogliate in un altro oggetto modello), ecc. Inoltre, un singolo modello può avere più viste.
3. Controllo: gestisce l'input esterno al sistema invocando modifiche sul modello. Il controllo / vista può essere strettamente correlato (nel caso di un'interfaccia utente). Tuttavia, è possibile elaborare altri input esterni (come i comandi di rete) che sono completamente indipendenti dalla vista.

Direi che MVC è un concetto o una famiglia di modelli simili.

Penso che questo articolo meriti di essere letto. Architetture GUI di Martin Fowler

Innanzitutto, devi determinare chi è il richiedente della domanda e che tipo di risposta sta cercando. Rispondi a questa domanda con un'altra domanda, ad esempio "In che senso?"

Puoi chiedere se si riferiscono a MVC in generale, una particolare implementazione di MVC (ad esempio asp.net MVC, MVC di primavera, MVC smalltalk, ecc.), Che cosa è tecnicamente, che cosa è filosoficamente (sì, ha un anche la filosofia), ecc.

Se questa è una domanda su un test e non si può chiedere al richiedente di chiarire, allora si dovrà indovinare in base al contesto.

Una risposta buona e semplice è:

MVC è un'architettura di interfaccia utente software utilizzata per separare le preoccupazioni strutturali e comportamentali al fine di facilitare software più gestibili.

Puoi anche dire:

Separando la vista dal controller dal modello, incoraggia l'isolamento dei componenti in base alle loro responsabilità. In teoria, e di solito in pratica, ciò aiuta a migliorare la manutenibilità impedendo alle diverse parti del sistema di mescolarsi e creare sistemi più complessi.

Ma, alla fine, sarai giudicato se dai la risposta che si aspettano. L'unica soluzione al problema è scoprire che tipo di risposta si aspettano.

Ecco cosa direi al riguardo. Vorrei provare a spiegarlo in termini di applicazioni mobili, perché è ciò che conosco di più e perché non credo di averlo compreso appieno prima di iniziare a fare applicazioni mobili.
Prendiamo ad esempio Android.
Livello di presentazione, ad es. l'interfaccia utente può (dovrebbe, il più delle volte è) essere specificata interamente in xml. Per semplicità, supponiamo che un file xml descriva una schermata nell'applicazione. Il file XML specifica i controlli, il layout dei controlli, il posizionamento, i colori, le dimensioni, le etichette delle stringhe ... tutto ciò che riguarda la presentazione. Eppure non sa nulla di quando verrà chiamato, quando verrà posizionato sullo schermo. Sarà un layout autonomo o una parte di un layout più grande? Ecco qua: la tua VISTA perfetta .

Ora, ovviamente, la vista deve essere posizionata sullo schermo ad un certo punto, quindi come dovrebbe farlo? Il tuo CONTROLLER , in Android chiamato Activity. Come dice il nome, l'attività fa alcune attività. Anche se il suo unico scopo è quello di visualizzare la vista definita nel passaggio 1, eseguirà alcune azioni. Quindi, l'attività recupera una vista e la visualizza sullo schermo. Poiché la vista non sa nulla sull'attività, allo stesso modo l'attività non sa nulla della presentazione effettiva. Noi (i programmatori) potremmo riorganizzare il layout della vista più volte, senza modificare nemmeno una riga di codice nella nostra attività.

Ora, non è molto utile presentare il tuo bel layout xml lucido e ben definito senza effettivamente fare qualcosa. Diciamo che vogliamo archiviare i dati inseriti dall'utente. L'attività deve affrontare questo processo dal prendere i dati dall'utente al passarli a qualcun altro per gestirli (elaborarli, archiviarli, eliminarli). A chi passerà? Bene, per un MODELLO . Mi piace pensare a un modello come puro. classe java che non sa nulla del contesto dell'applicazione in cui vive. (In pratica non sarà quasi mai il caso).

Diciamo che ho una persona di classe che ha tre proprietà: nome, indirizzo, età. Il mio layout definito XML ha 3 campi per l'input dell'utente: nome, indirizzo, età. La mia attività prende i tre valori dall'input dell'utente, crea un nuovo oggetto Person e invoca un metodo su di esso che sa come gestire una logica specifica della Persona. Ecco qua. Model-View-Controller.

Comincio sempre dicendo loro che lo schema non è qualcosa di nuovo ed è in circolazione da molti anni ... è a questo punto mi danno uno sguardo curioso e BAM !, sono agganciati:

E poi vorrei praticamente parlare dei vari punti come le risposte precedenti, ma penso che sia importante essere anche contestuali, come ha detto JB King, ASP.NET MVC, ecc.