Spiega Controller vista modello

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 pattern MVC con gli stessi Servlet. Quindi, cosa stai cercando di fare quando parli dell'applicazione di MVC, separa il Modello (la logica aziendale), la vista (la logica di presentazione) e il Controllore (il servlet del controller che delega il controllo alla logica aziendale appropriata).

In questo caso, MVC non si tratta solo di separare la business dal livello di presentazione e dal livello 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 ulteriori informazioni su Internet.

Per prima cosa penso che sia meglio parlare di ciò che è MVC Architecture e poi andare oltre nel modo in cui stai programmando.

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

1. Modello : rappresenta il tuo modello di dati, è il nucleo del sistema in cui tutte le informazioni ad esso correlate devono essere localizzate. Per esempio: se hai intenzione di creare 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 regole.

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

2. Controller : qui è dove avviene la magia e dove l'architettura stratificata incontra il paradigma orientato agli oggetti che era destinato a utilizzare. Qui è dove si implementa come reagisce il sistema quando qualche utente dell'applicazione richiede qualcosa sull'app vai all'interfaccia utente.

   The Controller should be able to handle the Model Objects, do operations with them to achieve what the user requested and then delegate the result to the corresponding View Layer to render it back to our user.

3. Visualizza : si tratta delle interazioni Start e End of User. Qui è dove si definisce come gli utenti interagiscono con l'applicazione. Oggigiorno è abbastanza comune che gli utenti provano ad accedere, ad esempio, ad applicazioni web di diversi tipi di media come: telefoni cellulari, tabelle, pc, computer portatili, ecc.

   Generalmente ogni tecnologia richiede 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 le interazioni siano tutte codificate, non c'è assolutamente alcun modo di riutilizzare il tuo codice in un modo non è CopyPaste. Il risultato è un codice che odora e molto tempo sprecato per adattare il sistema HOLE.

   La virtù di avere Visualizza in un livello separato, ci consente di funzionare indipendentemente dal Modello su cui stiamo lavorando . Abbiamo solo bisogno di sapere come dovremmo rendere l'elenco degli oggetti che il controllore ci sta inviando. Come ha generato è completamente banale

Quindi, finalmente abbiamo ottenuto un modello indipendente che potrebbe essere adattato come riteniamo opportuno in base alle nostre attuali esigenze (oggi devo gestire un gioco monoutente senza regole, domani potrei giocare con amici e ora il suo multiutente, e così via) che non dipende da come lo renderemo all'utente. Quindi, un Controller che acquisisce la richiesta degli utenti proveniente da una vista, elabora gli oggetti del modello e restituisce le informazioni alla vista per renderizzarle.

Torna alla prima domanda che hai posto: Come puoi vedere (spero) MVC sia un modo per fare cose e non una TECNOLOGIA per creare software. Potresti usare i tuoi java Servlet e implementare un'Achitecture MVC sotto di esso.

Ecco un Q & Un sito di esempio che utilizza un'architettura MVC per chiarire un po '

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

• Modello : i tuoi dati (non solo il tuo database!), il modello può anche essere un file ini o xml o dati da un servizio web). Le classi modello servono allo scopo di definire, assemblare e gestire i dati. Leggi l'eccellente articolo chiamato " The M in MVC: Perché i modelli sono incompresi e non apprezzati ". Il modello dovrebbe essere accessibile solo dal controller.
• Viste : il codice della tua GUI (presentazione). Dovrebbe solo accedere 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.

At it's core, MVC is a way to organize the responsibilities of your code so that it is modular, predictable, and robust.

La separazione ti consente le seguenti libertà:

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

Con attenzione, è 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 di 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. Questo includeva i concetti di "Convenzione sulla configurazione", mappando le azioni del controllore ai metodi di classe e le richieste di URL di instradamento al codice sottostante.