MVC: perché abbiamo bisogno di "controller", o quando dovremmo usare questo modello?

Question

Ho letto molte pubblicazioni su MVC, ma non riesco ancora a capire chiaramente perché abbiamo bisogno di "controller".

Io di solito scrivere le applicazioni nel modello client-server :

server di contiene tutte le business logica, e non sa nulla della gui. Fa il lavoro principale, ed è il più portabile possibile.

cliente è una GUI, si lega al server, interagisce con l'utente, invia i comandi dal utente al server.

mi piace questa architettura, e io non riesco a capire il motivo per cui la gente ha realmente bisogno un altro medium tra cliente e server di, che sembrano essere regolatore?

UPD: semplice esempio: supponiamo di dover scrivere un data logger. I dati provengono dalla porta COM, sono codificati da qualche protocollo. È necessario mostrare i messaggi ricevuti in una semplice finestra di registro.

Come dovrei farlo:

server di contiene i seguenti elementi:

• Data_receiver: riceve effettivamente i dati grezzi dalla porta COM, ma la sua interfaccia, quindi siamo in grado di fare un po ' un'altra classe che riceve dati da qualsiasi altra fonte;
• Data_decoder: prende i dati grezzi e restituisce i messaggi decodificati risultanti, è anche l'interfaccia, quindi possiamo cambiare facilmente il protocollo di codifica;
• Data_core: utilizzando istanze di Data_receiver e Data_decoder, emette segnali ai client.

cliente contiene i seguenti elementi:

• nucleo Appl: crea un'istanza della Data_receiver (quella che si collega alla porta COM), Data_decoder e Data_core (che prende i riferimenti a Data_receiver e Data_decoder casi) , crea anche una finestra di log semplice della GUI (che prende come riferimento Data_core);
• Finestra di registro semplice della GUI: si collega allo Data_core, ovvero ascolta i segnali emessi da esso e visualizza i dati ricevuti.

Come ho capito quello che ho letto su MVC, GUI non dovrebbe effettivamente prendere i messaggi ricevuti dalla Data_core, perché regolatore dovrebbe fare questo e poi passare i dati alla GUI. Ma cosa succede male se la GUI prende questi dati direttamente dal modello ?

Answer 1

"client-server" non ha nulla a che fare con MVC, afaik.

capisco come questo:

• Il Model è il modo di strutturare i dati.
• Il View è la rappresentazione visibile. (GUI)
• Il Controller utilizza la logica per controllare la vista e/o altra logica.

L'idea alla base è quella di dividere la rappresentazione visiva dalla logica. Quindi quando prendi la vista non duplichi la logica. ... quindi nel tuo caso potresti usare MVC solo dal lato client e hai bisogno di un controller, perché questo è il punto in cui avviene tutta la magia.

Answer 2

Penso allo schema MVVM nella lettura dei dettagli del modello client-server. Quando si desidera eseguire i test unitari, è meglio guardare la VM (ViewModel) come controller.

Seguendo lo schema, un classico schema client/server, il Controller, il Modello e la Vista risiedono nel codice server che si chiama Data_receiver, Data_decoder e Data_core. Nel tuo 'client' hai di nuovo un controller e guarda.

È utile separare dal codice server un controller che riceve e decodifica i segnali e i dati dal COM, un modello a cui il controller passa e riceve dati in rotta verso e dal database, una vista che codifica e formatta i dati grezzi dal modello.

Nel seguire il principio Non ripetere (DRY), è possibile notare che il codice del controller è presente sia nel server sia nelle porzioni client del codice in cui si ripete codice o responsabilità.

È utile quando si guida lo sviluppo in modalità Test Driven Development per separare parti distinte, in modo da poter allegare vari test.

Answer 3

Meglio tardi che mai Voglio correggere la tua interpretazione errata di "Perché è necessario un ulteriore livello tra client e server".

Se si passa attraverso le righe seguenti, la risposta è chiarissima che MVC è un modello triangolare di architettura.

La vista chiede la richiesta al modello, il modello chiede il controller, il controller lo elabora e lo invia alla vista.

The Model is the way you structure your data. 
The View is the visible representation. (GUI) 
The Controller uses the logic to control the view and/or other logic. 

saluti, Pavan.G

Answer 4

In passato mi hanno chiesto di me questa stessa domanda molte volte e mi sono state recentemente letto su modello JSP 2 architettura, e la voce di Wikipedia afferma quanto segue.

La letteratura sulla tecnologia Web-tier nella piattaforma J2EE utilizza frequentemente i termini "Modello 1" e "Modello 2" senza spiegazione. Questa terminologia deriva dalle prime bozze della specifica JSP, che descriveva due schemi di utilizzo di base per le pagine JSP. Mentre i termini sono scomparsi dal documento delle specifiche, rimangono di uso comune. Il modello 1 e il modello 2 si riferiscono semplicemente all'assenza o alla presenza (rispettivamente) di un servlet del controller che invia richieste dal livello client e seleziona le viste.

Ciò significa fondamentalmente che esistono variazioni al pattern MVC stesso in modo da poter applicare sempre un pattern MVC o MV a seconda del progetto. Tuttavia, una vera architettura MVC dovrebbe avere un controller in quanto il modello e la vista non dovrebbero parlare tra loro direttamente.