Modello di progettazione MVC. Come si adatta View?

Question

Ho una domanda sul modello di progettazione Model-View-Controller. Capisco che il modello contenga i dati. Capisco anche che il Controller (View Controller) implementa la logica dell'app. Ad esempio, se la rotellina UIPicker seleziona la riga 4, il controller di visualizzazione può richiedere al modello il 4o oggetto archiviato nell'array del modello. Ho difficoltà a capire se le "viste" si adattano. Penserei che quel file di pennino/storyboard sarebbe classificato come "Visualizza". Tuttavia, ogni visualizzazione richiede che un controller di visualizzazione sia collegato per collegare tutte le prese alla vista. Come suppongo di tenere separati View e View Controller? Dovrei collegare tutte le prese alla "View Class" e quindi nel mio View Controller fare riferimento alla mia classe "View" quando si implementa la logica di quelle prese? Forse ho solo bisogno di un esempio in cui View e View Controller gestiscono compiti diversi. Perché altrimenti la classe "View" in più non sembra avere senso. La vista di MVC si riferisce a una View Class? Come o perché dovrei voler separare questa View Class dalla mia classe View Controller?

Answer 1

Il lavoro di una vista è la visualizzazione di dati e la segnalazione di eventi.

Il lavoro del controller è di coordinare la comunicazione tra viste e modelli.

Il lavoro dei dati è dati di archivio e anche per fornire logica di business attorno a quei dati.

ti ha chiesto:

Sto avendo difficoltà a capire erano le "viste" in sintonia

Nel tuo esempio, il UIPickerView è la vista..

In iOS/OSX, un controller di visualizzazione è solo il controller di MVC. Accade solo che un controller di visualizzazione contenga anche un contenitore di viste vuoto a cui è possibile aggiungere tutte le altre viste. Ma c'è ancora una chiara separazione di MVC in iOS/OSX.

Tutte le classi come UIButton, UIPickerView, UITableView, ecc. Rappresentano la vista. Il compito di un controllore della vista è quello di fornire quelle viste con i dati dai modelli di dati e di rispondere agli eventi da quelle viste dandoti la possibilità di aggiornare altre viste e i modelli di dati.

È inoltre dichiarato:

Tuttavia ogni vista richiede che un controller di vista essere collegato a cablare tutti i punti vendita alla vista. Come suppongo di tenere separati View e View Controller?

Sono separati. Se aggiungi un UITableView, questa è una vista separata. Lo colleghi a una classe in modo che la classe possa implementare l'origine dati e delegare i metodi. Quella classe è una classe controller. È comune che questa classe controller sia un controller di visualizzazione ma non deve esserlo. È possibile scrivere tutti i tipi di classi di visualizzazione personalizzate che sono indipendenti da qualsiasi controller di visualizzazione specifico (o controller generico). Ma alla fine questa classe di visualizzazione deve essere collegata a una classe [view] controller in modo che i dati e gli eventi possano essere elaborati correttamente.

ti ha chiesto:

Come o perché dovrei voler avere questa Altri classe separata dal mio punto di vista classe Controller?

Vedere UITableViewController. Questo è un chiaro esempio della separazione ma è fornito in un pacchetto abbastanza accurato. In realtà hai una classe separata UITableView che è la vista. Questa vista è responsabile del rendering della vista e della raccolta dell'interazione dell'utente. È il controller della vista tabella effettivo che fornisce i dati alla vista e gestisce gli eventi utente dalla vista.

È possibile aggiungere viste UITableView a qualsiasi vista. Questo è un componente di visualizzazione completamente riutilizzabile. Ogni controller che si collega a una vista tabella può fornire tutti i dati appropriati e gestire correttamente le interazioni dell'utente.

Answer 2

Ok, cercherò di sistemare le cose un po '.

Il modello è denominato Model-View-Controller, quindi separa chiaramente il modello, la vista e il controller. Come hai giustamente sottolineato, ViewController mette insieme le cose (dalla vista e dal controller :) e in realtà il ViewController interrompe il pattern MVC forte. La buona notizia è che non devi separare la vista e il controller se stai usando un ViewController (indovina perché è chiamato così?).

Ora la mia nooby spiegazione del motivo per cui il design è quello che è:

Quando si separano con forza la visualizzazione e il controller che, fondamentalmente, guadagnare punti di credito per una buona progettazione. Tuttavia, a quanto pare, i due non sono così separati come vorremmo che fossero. Diverse rappresentazioni GUI di solito richiedono una diversa implementazione della vista e un adattamento del controller che controlla l'inoltro del Modello alla GUI, ad es. visualizzazione di testo in chiaro sulla console e disegno su una bitmap. Nel primo caso, il tuo Controller passerebbe una stringa alla vista da renderizzare, nel secondo avrebbe anche bisogno di impostare alcune coordinate per ottenere il rendering del testo nel posto giusto. Di conseguenza, il controller cambierà abbastanza spesso.

Il caso ideale sarebbe implementare il modello e il controller e fornire semplicemente visualizzazioni per tutto ciò che chiunque vedrà in diretta. Tuttavia, nelle situazioni di vita reale, il controller si adatterà molto probabilmente alla vista lasciando il modello da solo. Quindi la decisione progettuale di combinare la vista e il controllore con un ViewController che contiene una vista particolare e sa come usarla è solo un modo ragionevole per andare.

Answer 3

Bene per rispondere alla tua domanda, analizziamo MVC - Modello, Visualizza, Controller. Cosa va dove?

Il Il modello viene in genere considerato il livello "fa qualcosa". Ciò mantiene la logica aziendale e la logica dei dati. Il tuo modello dovrebbe essere FAT, non SKINNY, il che significa che dovresti avere molto del tuo codice nel Modello.

Il Controller, considero il livello "risposta". Qui è dove decidi tu cosa restituire all'utente, che si tratti di una vista o di un altro tipo di risposta, come JSON (particolarmente utile nelle risposte RESTful). È possibile utilizzare anche il modello, ma non è necessario creare troppa logica nel controller stesso. Dovresti avere un controller SKINNY.

Il View è in gran parte il markup per la pagina - l'HTML insieme ad altri markup per ottenere l'accesso al modello - questo dipende dal framework che si sta utilizzando. La mia esperienza è con MVC .NET, quindi vado con quello.Mescolato con l'HTML accederai agli elementi del Modello. Non ci dovrebbe essere una vera e propria logica nella vista, ma si possono fare cose del genere (utilizzando la sintassi Razor)

<div>@foreach person in Model.Users{ 
    <p>@person.FullName</p> 
} 
</div> 

Così si può vedere che la vista può avere qualche "logica di visualizzazione" (come, ad anello sulle persone e ottieni FullName) ma è tutto ciò che dovresti davvero avere lì.

Ecco una breve presentazione che spiega più su MVC, tra cui il motivo per cui la tua spiegazione iniziale di "Modello contiene i dati, controller contiene la logica" in realtà non è vero: http://www.slideshare.net/damiansromek/thin-controllers-fat-models-proper-code-structure-for-mvc

il pattern MVC design non include qualsiasi cosa si chiama "ViewController", che proviene da qualche altra parte.

Answer 4

In realtà ciò che si capisce è completamente sbagliato.

Il principio di base del modello di progettazione MVC è Separation of Concerns. Si separa il livello del modello dal livello di presentazione e (nel livello di presentazione) si separano le viste dal controller.

Ognuno di là pars hanno una responsabilità diversa:

• livello di modello contiene tutta la logica di business. Ciò include l'interazione con lo storage, la logica di dominio e la logica dell'applicazione.
• la vista è responsabile della logica dell'interfaccia utente. Nel contesto di Web ciò significa che la vista riguarda la creazione di risposta per l'utente
• controller è la parte che accetta l'input dell'utente e, in base a ciò, modifica lo stato del livello del modello e la vista corrente.

---

Ci sono un sacco di equivoco su MVC che le persone tendono a perpetuare. Ad esempio:

1. Alcuni insistono sul fatto che le visualizzazioni sono modelli stupidi. Non sono.

   Le viste nel modello di progettazione MVC sono istanze completamente funzionali che possono utilizzare o non utilizzare più modelli per generare la risposta.

2. Non ci sono "modelli". Il modello è un livello, costituito da più gruppi di classi, ciascuno con un compito specifico. Come non ci sono oggetti di "presentazione" per il livello di presentazione

3. I controllori non inviano dati dal livello del modello alle viste. Il controller cambia solo lo stato di altre parti della triade. Le istanze della vista richiedono di che cosa hanno bisogno dal livello del modello.