Vista corretta del modello -_____


14

Ho letto su Model View Controller, Model View Presenter, Model View ViewModel e così via, e in generale, il concetto di base sembra abbastanza semplice da capire: mantenere le belle visuali e il coraggio scientifico separati e ignoranti l'uno dell'altro come possibile. Non ottenere la logica burro di arachidi nel design cioccolato; bello, mi piace.

Il problema è che sono ancora un po 'confuso riguardo a quella terza parte ... quella non-modello-o-vista. Ognuno sembra avere la propria idea di come chiamarlo, cosa dovrebbe fare, cosa è giusto, cosa è semplicemente sbagliato ... e sto impazzendo cercando di capire quando un Presenter diventa un ViewModel e quando una Vista non dovrebbe ' lo farò perché quello è il lavoro del Presentatore e--

Sono sconclusionato.

Invece di chiedere a qualcuno di spiegare la differenza tra loro - perché è già stato fatto più volte (lo so; ho letto più articoli di quanti ne possa contare) - Sarei curioso di sentire i pensieri di un alcuni programmatori sul modello mi sono messo insieme.

Detto questo, come classificheresti questo design e , cosa forse più importante, vedi qualcosa che ovviamente fa schifo? Certo, mi piacerebbe sapere che sto andando bene se questo è davvero un design solido, ma preferirei ricevere consigli solidi sull'elogio.

Nota: userò "the Bridge" per la misteriosa terza parte di Model-View-? per evitare eventuali suggerimenti inconsci di ciò che "dovrebbe" essere.

Modello

  • È l'autorità sui dati.
  • Riceve informazioni sulle modifiche richieste dal Bridge.
  • Contiene ed esegue tutta la logica per come i dati si collegano ad altri dati.
  • Informa il Bridge quando i dati cambiano (per i dati a cui il Bridge ha espresso interesse). Modifica del testo: consente agli abbonati esterni (di cui non sa nulla) di monitorare il suo stato o i risultati del calcolo.
  • Conoscenza zero della vista.

Visualizza

  • Si preoccupa di fornire all'utente un modo per visualizzare e manipolare i dati.
  • Riceve informazioni sugli aggiornamenti dei dati da Bridge.
  • Contiene ed esegue tutta la logica su come presentare dati e controlli all'utente.
  • Informa il Bridge quando l'utente ha eseguito un'azione che (possibilmente) influenza il Modello.
  • Informa il Bridge di quali informazioni sono interessate.
  • Conoscenza zero del modello.

ponte

  • È coordinatore e traduttore tra il modello e la vista.
  • Apporta le modifiche di formattazione appropriate alle informazioni trasmesse tra il modello e la vista.
  • Conserva le informazioni su "chi ha bisogno di sapere cosa".
  • Conosce sia il modello che la vista.

Note aggiuntive

  • Nei programmi più complicati, è comune che ci siano più modelli. In questa situazione, il Bridge in genere assume il compito di coordinare / tradurre tra i vari Modelli e diventa quindi l'autorità su quale protocollo / API / modello Modelli dovrebbero essere costruiti. (ad esempio se si crea un programma di gioco di carte e si desidera costruire un modello di mescolanza del mazzo alternativo, è necessario utilizzare il Bridge per determinare quali funzioni sono necessarie per comunicare correttamente con il Bridge.)
  • Nei piccoli programmi semplici con una sola vista e modello, è comune per il Bridge "assumere" quale funzionalità è disponibile su entrambi i lati. Tuttavia, man mano che i programmi diventano più complessi, si consiglia alle View e ai Model di segnalare le proprie funzionalità al Bridge in modo da evitare inefficienze e ipotesi errate.

Penso che quasi lo copra. Sinceramente, accolgo con favore qualsiasi domanda tu possa avere in merito al design che tendo a utilizzare e allo stesso modo incoraggio qualsiasi suggerimento.

E come sempre, grazie per il tuo tempo.


2
Il blocco Visualizza presenta un errore di copia-incolla. Immagino che l'ultimo proiettile dovrebbe leggere "Ha una conoscenza zero del modello". E l'ultima frase della prima nota aggiuntiva dovrebbe probabilmente terminare con "modello" non "ponte" ??
Johannes S.

Risposte:


7

La tua frase

"È coordinatore e traduttore tra il modello e la vista."

indica che Bridge è il Presenter in un'architettura MVP.

MVP e MVC sono molto simili, tranne per il fatto che in MVP solo il Presenter osserva il Modello mentre in MVC alla Vista è anche consentito osservare direttamente il Modello (senza il Presenter come "Bridge").

La tua responsabilità di modello

"Informa il Bridge quando i dati cambiano (per i dati a cui il Bridge ha espresso interesse)."

è forse mal definito o forse un errore: non si desidera che il Modello abbia una dipendenza dal Bridge / Presenter / Controller o dalla Vista. Al contrario, si utilizza un modello Observer, Eventi o Programmazione reattiva per consentire a Bridge di iscriversi alle modifiche nel modello. E poi puoi riformulare la tua responsabilità come:

"Consente agli abbonati esterni (di cui non sa nulla) di monitorare i risultati di stato o di calcolo".

Se il modello non ha dipendenze dal controller o dalla vista, è più facile da testare e molto più portatile.


1
Se la differenza fondamentale è se la vista può o non può osservare il modello, allora il design è decisamente più MVP; la vista e il modello non sono mai autorizzati a parlare direttamente nel design che ho usato.
KoratDragon il

La responsabilità del modello era una formulazione scadente, credo. Il Modello non ha davvero idea o cura del chi / cosa / perché delle cose che vogliono ascoltarlo, ma pubblicherà semplicemente le modifiche che sono state apportate ai suoi abbonati. È perfettamente contento di esistere da solo senza abbonati di alcun tipo e non tenta di sollecitare nuovi abbonati.
KoratDragon il

1
Sembra che tu abbia un buon design, quindi. PS Il motivo per considerare MVC su MVP è che, senza disciplina, il Presenter può diventare sovraccarico.
Larry OBrien,

1
+1 per indicare semplicemente la differenza tra MVC e MVP. Come OP, il resto di Internet mi ha lasciato completamente perso sul fatto che questi acronimi fossero anche leggermente diversi.
Ixrec,

5

Ho il sospetto che una delle cose che ti confondano sia che ci sono due schemi completamente diversi che sono entrambi comunemente chiamati modello-view-controller.

C'è l'originale, come implementato in smalltalk e che è utile per i sistemi di gui locali, e c'è quello che tendo a pensare come web-mvc, che scambia alcune delle responsabilità delle viste e dei controller in modo che i controller possano sedere sul server con viste sul client (forse come html renderizzato, o forse tramite ajax).

La tua descrizione mi sembra come se si trovasse nella maggior parte delle definizioni di web-mvc.


Questo potrebbe spiegare perché ho avuto così tanti problemi a avvolgere la testa attorno al concetto. Grazie; è bello sapere che (probabilmente) non sto facendo nulla di tremendamente sbagliato nel concetto di MVC.
KoratDragon il

Per le moderne applicazioni Web a pagina singola, torniamo al modello MVC classico sul lato client.
Kevin Cline,

2

C'è molta discussione nella comunità di programmazione su questa esatta nomenclatura. Nessuno sembra essere d'accordo su molto di niente.

Per me, il modo in cui il bridge è collegato alla vista determina principalmente il nome.

  • Se può esserci una raccolta di viste per bridge, il bridge è un controller.
  • Se c'è sempre una vista per bridge, allora il bridge è un presentatore.
  • Se può esserci una raccolta di ponti per vista, allora il ponte è un modello di vista.

A volte le cose non sono così chiare. Ad esempio, un relatore potrebbe essere collegato a una vista composita composta da più visualizzazioni secondarie o un controller potrebbe essere creato senza alcuna conoscenza delle sue visualizzazioni. Nonostante ciò, penso che le mie regole siano un buon inizio.


Come nota a margine, mi piace abbinare le responsabilità in questo modo:

Modello

Responsabilità primaria: persistenza dei dati
Ruoli secondari: convalida degli aggiornamenti, notifica agli osservatori degli aggiornamenti

Visualizza

Responsabilità primaria: dati attuali
Ruoli secondari: accettare input, presentare UX

ponte

Responsabilità primaria: aggiornamento dati
Ruoli secondari: input pulito, sincronizzazione dati e viste


0

Mentre il modello suggerito sembra corretto in superficie e senza dubbio funzionerà per piccole istanze, man mano che l'app diventa più complessa, incontrerai problemi in cui non sei sicuro di cosa aggiorna cosa, chi ascolta dove e perché sto provando controllare così tanti modelli da così tante viste, tutti coloro che hanno bisogno di accedere a vicenda, ecc.

Consiglio di estendere le tue idee usando il seguente schema (tratto dal discorso di Amy Palamountain Enemy of the State ):

Modelli

  • Sincronizza lo stato con l'archivio dati
  • Gestire la convalida di dati nuovi / aggiornati
  • Genera eventi quando cambiano stato

Visualizzazioni

  • Modelli di rendering
  • Gestire gli eventi del modello
  • Gestisci eventi DOM
  • Media l'interazione tra Model e DOM

Controller

  • Gestisce al massimo un paio di modelli e viste
  • Tiene traccia delle visualizzazioni all'interno di un contenitore

moduli

  • Il raggruppamento logico di un controller e delle sue viste e modelli
  • testabile
  • Piccolo e mantenibile (responsabilità singola)
  • Coordina (tramite il Controller) lo stato e gli eventi delle Viste e dei Modelli in esso contenuti
  • Liberi di presentare le proprie opinioni
  • Non è libero di scegliere dove presentare le sue viste

Responsabile del layout

  • Responsabile della composizione del layout
  • Definisce una shell dell'applicazione nel DOM con aree in cui i moduli possono presentare il loro contenuto

Dispatcher

  • Ascolta gli eventi (tramite lo stream globale PubSub)
  • Responsabile del caricamento di nuovi moduli basati sugli eventi
  • Passa i moduli caricati al gestore del layout
  • Gestisce l'intera durata del modulo (creazione, pulizia, memorizzazione nella cache, ecc.)
  • Esempi di eventi:
    • Cambiamenti di rotta (compresa la rotta di carico iniziale)
    • Interazione dell'utente
    • Evento del modulo bollato da un evento Modello a causa di un cambiamento di stato sul lato server, ecc

Applicazione

  • Responsabile della configurazione generale, crea istanze come:
    • Dispatcher
    • Router
    • Stream di PubSub
    • logger
    • eccetera

Questo tipo di pattern consente di comporre l'applicazione, testare l'unità, rimuove la complessità che un Bridge potrebbe accumulare nel tempo, mantiene le preoccupazioni ben separate, ecc.

Come sottolinea Amy: fai attenzione a non creare un server sul client. E fai attenzione a non cadere nella dottrina di "Sto realizzando un framework MV *, quindi devo ___!" Prendi invece tutte queste idee (e le altre risposte qui) e trova ciò che funziona meglio per la tua applicazione e il tuo team.

Consiglio vivamente di guardare il discorso di Amy Palamountain Enemy of the State (da cui provengono queste idee), o almeno di guardare oltre le diapositive del discorso .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.