Spiegare Model View Controller

La mia esperienza con lo sviluppo di siti Web dinamici è limitata principalmente ai servlet Java. Ho usato Tomcat per sviluppare vari servlet Java e non esiterei a dire che sono abbastanza abile con questa tecnologia, così come con HTML / CSS / Javascript sul lato client per il front-end.

Quando penso a "sito Web dinamico", penso: l'utente richiede un URL con una stringa di query, il server riceve la query e quindi procede all'output HTML in modo dinamico per rispondere alla query. Ciò comporta spesso la comunicazione con un database al fine di recuperare i dati richiesti per la visualizzazione. Questa è fondamentalmente l'idea alla base del doGetmetodo di Java HttpServlet.

Ma oggigiorno sto ascoltando sempre di più nuovi framework come Django e Ruby on Rails, che sfruttano tutti l'architettura "Model View Controller". Ho letto vari articoli che spiegano MVC, ma ho difficoltà a capire davvero i vantaggi. Capisco che l'idea generale è quella di separare la logica di business dalla logica dell'interfaccia utente, ma non riesco a vedere come questo sia qualcosa di veramente diverso dalla normale programmazione web. La programmazione Web, per sua natura, ti costringe a separare la logica di business (programmazione lato server back-end) dalla programmazione UI (HTML o Javascript lato client), perché i due esistono in sfere di programmazione completamente diverse.

Domanda: Che cosa MVC offerta per qualcosa come un servlet Java, e ancora più importante, che cosa esattamente è MVC e come è diverso da quello che normalmente fare per sviluppare un sito web dinamico utilizzando un approccio più tradizionale, come un servlet Java (o anche qualcosa di più vecchio come CGI)? Se possibile, quando si spiega MVC, fornire un esempio che illustri come MVC viene applicato al processo di sviluppo Web e come sia vantaggioso.

In primo luogo penso che sia meglio parlare di ciò che è MVC Architecture e poi andare oltre nel modo in cui stai attualmente programmando.

L'architettura MVC è un modo per organizzare il flusso di lavoro all'interno di un sistema sotfware, pensarlo come un modo stratificato per implementare il comportamento del sistema. Questi livelli sono:

1. Modello : rappresenta il modello di dati, è il nucleo del sistema in cui devono essere localizzate tutte le informazioni ad esso correlate. Quindi, per esempio: se stai per progettare un Gioco, avrai bisogno di Giocatori, Regole, Ostacoli e alcune logiche relative alle interazioni di questi elementi come: I Giocatori dovrebbero essere in grado di ordinare Ostacoli quando si applicano alcune serie di Regole.

   Il modello è il primo che dovresti pensare perché sarà il centro delle tue applicazioni .

2. Controller : è qui che accade la magia e dove l'architettura a strati incontra il paradigma orientato agli oggetti che doveva usare. Qui è dove si implementa come reagisce il sistema quando alcuni utenti dell'applicazione richiedono qualcosa sull'app vai all'interfaccia utente.

   Il controller dovrebbe essere in grado di gestire gli oggetti modello, eseguire operazioni con essi per ottenere ciò che l'utente ha richiesto e quindi delegare il risultato al livello di visualizzazione corrispondente per restituirlo al nostro utente.

3. Visualizza : questo è il punto iniziale e finale delle interazioni dell'utente. Qui è dove si definisce come gli utenti interagiscono con l'applicazione. Al giorno d'oggi è abbastanza comune che gli utenti provino ad accedere, ad esempio, ad applicazioni web da diversi tipi di media come: telefoni cellulari, tavoli, pc, laptop, ecc.

   Generalmente ogni tecnologia ha bisogno di un linguaggio diverso per creare la vista, quindi immagina che il tuo modello di dati e il modo in cui il modello interagisce e il modo in cui rendi le interazioni siano codificate, non c'è assolutamente modo di riutilizzare il tuo codice in un modo che non sia CopyPaste . Il risultato è un codice che puzza e un sacco di tempo sprecato nell'adattare il sistema HOLE.

   La virtù di avere la vista in un livello separato, ci consente di lavorare indipendentemente dal modello su cui stiamo attualmente lavorando . Dobbiamo solo sapere come dovremmo eseguire il rendering dell'elenco di oggetti che il controller ci sta inviando. Come l'ha generato è completamente banale

Quindi, finalmente abbiamo ottenuto un modello indipendente che potrebbe essere adattato come meglio crede in base alle nostre esigenze attuali (oggi devo gestire un gioco monoutente senza regole, domani voglio giocare con gli amici e ora il suo multiutente, e così via) ciò non dipende da come lo renderemo all'utente. Quindi, un controller che acquisisce le richieste degli utenti provenienti da una vista, elabora oggetti modello e quindi restituisce le informazioni alla vista per renderle.

Torna alla prima domanda che hai posto: come puoi vedere (spero) MVC è un MODO per fare le cose e non una TECNOLOGIA per creare software. È possibile utilizzare i servlet java e implementare un Achitecture MVC al suo interno.

Ecco un sito di domande e risposte che utilizza un'architettura MVC per chiarire un po '

Per rispondere alla tua domanda

What does MVC offer over something like a Java servlet

MVC è un modello, non una tecnologia. Quindi il pattern può essere applicato anche durante la programmazione con Servlet.

Vorrei provare a spiegare il modello MVC con i Servlet stessi. Quindi, quello che stai cercando di fare quando parli dell'applicazione di MVC è, separare il Modello (la logica aziendale), la vista (la logica di presentazione) e il Controller (il Servlet del controller che delega il controllo alla logica aziendale appropriata).

In questo caso, MVC non si limita a separare il business dal livello di presentazione e dal livello del controller, ma il livello aziendale non sa nemmeno che esiste un controller o una presentazione.

I principali framework in Java come Struts seguono questo schema. Penso che tu abbia sbagliato il concetto. Puoi leggere di più al riguardo su Internet.

MVC è davvero facile da comprendere, è solo un modello di progettazione, tuttavia, ho visto che la parte più difficile / supervisionata è la parte del modello.

• Modello : i tuoi dati (non esclusivamente il tuo database !, il modello può anche essere un file ini o xml o dati da un servizio web). Le classi di modelli hanno lo scopo di definire, assemblare e gestire i dati. Leggi l'eccellente articolo intitolato " La M in MVC: perché i modelli sono fraintesi e non apprezzati ". È possibile accedere al modello solo dal controller.
• Visualizzazioni : il tuo codice GUI (presentazione). Dovrebbe accedere solo al controller
• Controller : la tua logica. Gestisce la comunicazione tra modello e vista.

Il concetto di Model-View-Controller non è una novità. È iniziato con Smalltalk intorno al 1979.

Fondamentalmente, MVC è un modo per organizzare le responsabilità del codice in modo che sia modulare, prevedibile e robusto.

La separazione ti consente le seguenti libertà:

• Capacità di evolvere il modello senza influenzare la logica dell'applicazione o visualizzare i dati
• Capacità di modificare la logica aziendale senza influire sul modello (ad esempio aggiungere nuovi passaggi, ecc.)
• Capacità di rappresentare il modello in diversi modi

Con cura, potenzialmente è possibile progettare il modello e il controller in modo da poter sostituire completamente un'applicazione desktop con un'applicazione Web come front-end.

Più recentemente, l'approccio Ruby on Rails a MVC ha introdotto alcuni concetti più recenti che sono stati copiati in quasi tutti i framework di applicazioni Web in stile MVC. Ciò includeva i concetti di "Convenzione sulla configurazione", il mapping delle azioni del controller ai metodi di classe e il routing delle richieste URL al codice sottostante.