• Il Model (modello), cioè l’impianto logico dell’applicazione (database, collezioni di informazioni, connessioni a host, fruizione di servizi, ecc.);

• La View (vista), cioè il livello di presentazione dell’applicazione, sia nel caso in cui si debba avere una interazione con un utente umano sia nel caso in cui debbano dialogare più applicazioni;

• Il Controller (controllore), cioè il “direttore d’orchestra” di tutta l’attività, che raccoglie le richieste in input, attiva gli oggetti necessari del modello e, attraverso essi, produce i dati da affidare alla vista per la presentazione.

I vantaggi sono evidenti.
Si possono ulteriormente isolare diversi ambiti di complessità di un progetto. Si può lasciare che chi si occupa del modello interagisca con chi progetta i database, mantenendo una certa libertà di sviluppo. Nello stesso tempo, chi si occupa della vista può concentrarsi sull’usabilità, i rapporti con i grafici e le problematiche di accessibilità. E chi si occupa del controllore può occuparsi del funzionamento generale dell’applicazione, senza sapere cosa succede nelle altre stanze dello sviluppo.

Inoltre sarà possibile, con relativa disinvoltura, modificare una sola parte dell’applicazione, senza travolgere il resto.
Immaginiamo, ad esempio, la penosa fatica di cambiare la struttura di un database (o l’RDBMS stesso) in una applicazione non strutturata in questo modo: bisognerebbe cercare le query in tutta l’applicazione per adattarle ai nuovi formati. Oppure potrebbe essere di impatto disastroso la modifica di un layout di presentazione, se il layout non fosse stato isolato ma costruito “pezzo per pezzo” nel corso del flusso dei programmi.

Quando si programma a oggetti, lo schema MVC è ampiamente riconosciuto come estremamente vincente ed è anche concettualmente piuttosto semplice.
Operativamente, però, realizzare un progetto che rispetti lo schema MVC può essere un compito piuttosto complesso.