L'utente interagisce con Visualizza , ma View deve comunicare le azioni al Controller . Controller può aggiornare il Modello , ma non è richiesto con ogni / qualsiasi cambiamento.
La descrizione che sto fornendo si basa sulla mia esperienza personale con l'implementazione .NET di MVC. La tua implementazione può essere diversa.
Il Controller è dove vengono elaborate le azioni, fondamentalmente un livello aziendale. Un controller semplice non farà altro che ottenere i dati dal modello per alimentare la vista. Un controller complicato eseguirà tutti i tipi di azioni, fino alla gestione della sicurezza, all'autenticazione, all'autorizzazione, alla registrazione e probabilmente a molte altre cose.
La Vista dovrebbe essere responsabile solo della visualizzazione delle informazioni in modo che l'utente possa capire. Ci possono essere alcuni passaggi qui sopra sia con il Controller che con il Modello, in quanto cose come le Single Page Applications (SPA) avranno feedback di validazione dei dati per l'utente. Qualsiasi altro cross over è strongmente disapprovato.
Il modello riguarda i dati. Ciò include la convalida dei dati (ove applicabile). Anche la memorizzazione e il recupero dei dati vengono gestiti in questo livello.
Aggiorna
Sembra che ci sia una certa confusione intorno a chi fa cosa quando. Ho incluso due panoramiche diverse delle architetture MVC perché sono simili, ma non uguali. C'è spazio per entrambe le interpretazioni. Forse, molti altri. Le descrizioni di cui sopra sono la mia interpretazione di MVC da più fonti, inclusa la mia esperienza nella creazione di applicazioni che utilizzano questa metodologia. Si spera che questo aggiornamento aiuti a chiarire parte di questa confusione.
MVC è un tentativo di creare un modello di progettazione Separazione dei dubbi per lo sviluppo del software. È stato principalmente implementato in applicazioni web (per quanto ne so).
La vista gestisce tutte le interazioni dell'utente. Se l'utente fa clic su un pulsante, la vista determina se il clic è un'interazione dell'interfaccia utente o qualcosa che va oltre la sua preoccupazione (un'interazione del controller). Se il pulsante fa qualcosa come copiare valori da un campo a un altro, l'implementazione determinerà se si tratta di un problema di visualizzazione o di un problema relativo al controller. Molto probabilmente avrai solo questa confusione di preoccupazioni quando gestisci una singola pagina di applicazione (SPA).
Il Controller è dove vengono elaborate le tue azioni. La vista ha comunicato che l'utente ha deciso di modificare i valori per alcuni campi. Il Titolare può eseguire la convalida su tali dati o può essere gestito dal Modello. Di nuovo questo dipende dall'implementazione. Se il controller ha caratteristiche di sicurezza, può determinare che l'utente non disponga di privilegi sufficienti per eseguire l'azione. Rifiuterebbe le modifiche e aggiornerà la vista di conseguenza. Il Controller determina anche quali dati recuperare dal Modello, come impacchettarlo e aggiornare la Vista con quei dati.
Il modello determina come e dove archiviare i dati. Può anche eseguire la convalida di tali dati prima di memorizzarli (dovrebbe farlo perché le persone ignoreranno la vista a volte).
Wikipedia ha un articolo su MVC .
- A model notifies its associated view/views and controllers when there has been a change in its state. This notification allows views to update their presentation, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be "passive," so that other components must poll the model for updates rather than being notified.
- A view is told by the controller all the information it needs for generating an output representation to the user. It can also provide generic mechanisms to inform the controller of user input.
- A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).
Da Microsoft's Overview of MVC .
-
Models. Model objects are the parts of the application that implement the logic for the application's data domain. Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in a SQL Server database.
In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a dataset and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the dataset takes on the role of a model object.
Views. Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.
Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn might use these values to query the database.