Qual è la differenza tra ViewModel e Controller?

Question

Quali sono le responsabilità dell'uno contro l'altro? Che tipo di logica dovrebbe andare in uno contro l'altro? Quale colpisce servizi e database? Come posso decidere se il mio codice deve andare nel viewmodel o nel controller?

Per la cronologia, sto usando ASP MVC, ma poiché la domanda è architettonica, non credo che importi quale sia il linguaggio o il framework che sto usando. Invito tutti gli MVC a rispondere

Answer 1

Il ViewModel è un modello utilizzato per gestire la logica di presentazione e lo stato della vista e il controllore è uno dei fondamenti parti di qualsiasi MVC quadro, per qualsiasi richiesta HTTP e Orchest tutte le azioni successive raggiungimento di una risposta http

il pattern ViewModel:. More info

nel modello ViewModel, l'interfaccia utente e qualsiasi logica UI sono incapsulati in un Visualizza. La vista osserva un ViewModel che incapsula la logica di presentazione e lo stato. Il ViewModel a sua volta interagisce con il modello e funge da un intermediario tra esso e la vista .

View <-> ViewModel <-> Model 

I controllori (deriva dal modello Front Controller): More Info

E "fornisce un punto di ingresso centralizzato per la gestione delle richieste."

HTTP Request -> Controller -> (Model,View) 

Differenze --Plain: -

• Mentre il ViewModel è un modello opzionale Controller è un must, se si sta andando nella direzione MVC.
• ViewModel incapsula lo stato e la logica di presentazione di , Il controller controlla tutto il flusso di applicazioni .

Answer 2

Modello rappresenta i tuoi dati e il modo in cui viene manipolato. Quindi, il modello tocca il DB.

View è l'interfaccia utente.

Controler è la colla tra di loro.

Answer 3

Alcuni logica e modello devono essere invocati per generare alcuni dati (strutturati o semi-strutturati). Da questi dati la pagina restituita/JSON/ecc. viene creato, in genere con una logica di struttura rudimentale.

La prima parte (creazione dei dati) viene eseguita dal controller (tramite il modello in genere). La seconda parte - dal View. ViewModel è la struttura dati che viene passata tra controller e vista e in genere contiene solo accessor.

Answer 4

Il Model-View-Controller (MVC) è un modello di progettazione architettonica che esiste, principalmente, per separare la logica di business dalla presentazione. Fondamentalmente, non vuoi che il tuo back-end tocchi il tuo fronte. Sembra in genere come questo:

I motivi per fare questo è perché, separando il back-end e la parte anteriore, non si leghi la tua interfaccia utente direttamente ai dati/lavoro. Ciò consente di inserire nuove interfacce nella logica aziendale senza influire su detta logica. Inoltre, migliora anche la facilità di test.

Un semplice esempio di dove MVC è utile - diciamo che hai un'applicazione che gestisce le finanze della tua azienda. Ora, se stai utilizzando correttamente MVC, puoi avere un front-end che si trova presso la scrivania di un finanziere e gli consente di gestire le transazioni, gestire le finanze, ecc. MA, perché la logica di business è separata, puoi anche fornire un front-end al tuo CEO Blackberry che gli permette di vedere lo stato attuale del business. Poiché i due front-end sono diversi, possono fare cose diverse pur fornendo (diversi tipi di) accesso ai dati.

EDIT:

Dal aggiornati tua domanda un po ', io aggiornare la mia risposta. Non esiste una scienza perfetta per la separazione di MVC. Ci sono alcune buone regole pratiche, tuttavia. Ad esempio, se si sta parlando di componenti della GUI, questa è probabilmente una vista. (Stai parlando di aspetto grafico, usabilità, ecc.) Se stai parlando di dati e del lato "business" della casa (database, logica, ecc.), Probabilmente stai facendo riferimento a un modello. E, tutto ciò che controlla l'interazione tra i due è molto probabilmente un controller.

Inoltre, è necessario notare che, mentre le viste e i modelli sono in genere separati "fisicamente", un controllore può esistere con una vista quando ha senso.

Si ha ragione quando si dice che il framework (o anche la lingua) per MVC non ha importanza. Il pattern stesso è indipendente dal linguaggio e descrive davvero un modo per architettare il tuo sistema.

Spero che questo aiuti!

Answer 5

Penso che ci sia un certo valore nell'apprendimento della dottrina ricevuta. Ma c'è anche valore nel comprendere come la dottrina è venuta ad essere così com'è.

Trygve Reenskaug è ampiamente riconosciuto con l'invenzione di MVC. L'articolo di N. Alex Rupp Beyond MVC: A new look at the servelet architecture include una cronologia di MVC. In una sezione del lavoro di Reenskaug del 1978 presso il centro di ricerca Xerox Palo Alto, c'è un collegamento al suo documento Thing-Model-View-Editor: an Example from a planningsystem. Lì i pezzi sono descritti in questo modo.

Thing

qualcosa che è di interesse per l'utente. Potrebbe essere concreto, come una casa o un circuito integrato . Potrebbe essere astratto, come una nuova idea o opinioni su un foglio. Potrebbe essere un intero, come un computer o una parte, come un elemento del circuito.

Modello

Un modello è una rappresentazione attiva di un'astrazione in forma di dati in un calcolo sistema

View

Per qualsiasi dato modello è allegata una o più viste, ciascuna delle quali è in grado di mostrare mostrando una o più rappresentazioni grafiche del modello sullo schermo e su supporto cartaceo. Una vista è inoltre in grado di eseguire tali operazioni sul modello che è associato in modo ragionevole a con quella vista.

Editor

Un Editor è un'interfaccia tra un utente e una o più viste. Fornisce all'utente un sistema di comando adatto, ad esempio sotto forma di menu che possono cambiare dinamicamente in base al contesto corrente. Fornisce le viste con il coordinamento necessario e i messaggi di comando .

Rupp identifica Editor di Reenskaug come controller o strumento.

Le triadi MVC sono emerse in SmallTalk-80. Il modello era un'astrazione del concetto del mondo reale, la vista era la sua rappresentazione visiva, e il controller erano i pulsanti e le barre di scorrimento che permettevano all'utente di interagire con esso (in tal modo "controllando" la vista). Tutti i pezzi della triade erano interconnessi e potevano comunicare con gli altri due pezzi, quindi non c'era nessuna stratificazione o astrazione. Da allora, Reenskaug ha "preferito utilizzare il termine Strumento piuttosto che Controller."Secondo le sue note, questi sono i termini che ha usato nelle implementazioni successive

Answer 6

MVC sta per Modello, Visualizza, Controller.

Modello = dati (tabelle di database)

View = HTML, CSS, JavaScript, ecc

controller = logica principale, un contratto tra modello & View.

In termini semplici e afferrabili,

MVC consente di sviluppare le applicazioni in modo che i dati aziendali e dati di presentazione sono separati. Con questo, uno sviluppatore e un designer possono lavorare indipendentemente su un'app MVC senza il loro conflitto di lavoro. MVC rende la tua app disponibile anche per OOP.

Answer 7

• Il ViewModel può essere sul lato client e lato server. Ovunque si trovi, l'unico scopo di viewmodel è riprodurre i dati di presentazione .
• In architettura MVC Viewmodel non è obbligatorio ma senza controller la richiesta dal client non può essere elaborata.
• Il controller può essere visualizzato come interfaccia principale tra client e server per ottenere qualsiasi risposta dal server. Elabora la richiesta del cliente, recupera i dati dal repository e quindi prepara i dati della vista. Viewmodel può essere visualizzato come view data processor/presenter quindi un'interfaccia per gestire la vista in modo più eloquente.
• Nel contesto generale di un'applicazione Web, possiamo dire che il controller è il gestore della richiesta dell'applicazione mentre viewmodel è solo il gestore dell'interfaccia utente.