Design modello-Vista -

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: mantieni la grafica carina e le budella scientifiche separate e ignoranti l'un l'altro il più possibile Non si ottiene il burro di arachidi logico nel cioccolato di design; bello, mi piace.

Il problema è che sono ancora un po 'confuso da quella terza parte ... quella non-modello-o-vista. Tutti sembrano avere la loro idea di come chiamarla, 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é è il lavoro del Presentatore e -

Sto vagando.

Piuttosto che chiedere a qualcuno di spiegare la differenza tra loro - perché è già stato fatto più e più volte (lo so, ho letto più articoli di quanti ne possa contare) - Sarei curioso di sentire il pensieri di alcuni programmatori sul modello che ho messo insieme io stesso.

Detto questo, come classificheresti questo disegno come e forse ancora più importante, vedi qualcosa su questo che ovviamente fa schifo? Certo, mi piacerebbe molto sento che sto facendo del bene se questo è veramente un progetto solido, ma preferirei molto ricevere dei solidi consigli sull'elogio.

Nota: userò "the Bridge" per la misteriosa terza parte di Model-View-? per evitare qualsiasi suggerimento inconscio di ciò che "dovrebbe" essere.

Modello

  • È l'autorità sui dati.
  • Riceve informazioni sulle modifiche richieste da Bridge.
  • Contiene ed esegue tutta la logica per il modo in cui i dati si riferiscono ad altri dati.
  • Informa il Bridge quando i dati cambiano (per i dati che il Ponte ha espresso interesse in). Modifica parole: consente ai sottoscrittori esterni (di cui non sa niente) di monitorare i risultati dello stato o 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 per come presentare dati e controlli all'utente.
  • Informa il Bridge quando l'utente ha eseguito un'azione che (probabilmente) ha effetto sul Modello.
  • Informa il bridge a quali informazioni è interessato.
  • Conoscenza zero del modello.

Ponte

  • È il coordinatore e il traduttore tra il Modello e la Vista.
  • Apporta qualsiasi modifica di formattazione appropriata alle informazioni che vengono passate tra il Modello e la Vista.
  • Mantiene le informazioni su "chi deve sapere cosa".
  • Conoscenza del modello e della vista.

Note aggiuntive

  • Nei programmi più complicati, è comune che ci siano più modelli. In questa situazione, il Bridge assume in genere il compito di coordinare / tradurre tra più Modelli, e quindi diventa l'autorità su quali modelli di protocall / API / design devono essere costruiti. Ad esempio, se si crea un programma di gioco di carte e si desidera creare un modello di mescolamento del mazzo alternativo, è necessario utilizzare Bridge per determinare quali funzioni sono richieste per una comunicazione corretta 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, è consigliabile che la (e) Vista (i) e il (i) Modello (i) riportino le loro funzionalità al Bridge in modo che possa evitare inefficienze e assurde supposizioni.

Penso che lo copra. Con ogni mezzo, accolgo con favore qualsiasi domanda tu possa avere sul design che tendo ad usare, e incoraggio ugualmente qualsiasi suggerimento.

E come sempre, grazie per il tuo tempo.

    
posta KoratDragonDen 30.10.2014 - 17:19
fonte

4 risposte

7

La tua frase

"Is the coordinator and translator between the Model and the View."

indica che Bridge è Presenter in un'architettura MVP.

MVP e MVC sono molto simili, tranne che in MVP solo il Presenter osserva il Modello mentre in MVC è anche possibile osservare direttamente il Modello (senza Presenter come "Ponte").

Responsabilità del tuo modello

"Informs the Bridge when data changes (for data the Bridge has expressed interest in)."

è forse mal formulato o forse un errore: non vuoi che il modello abbia una dipendenza da Bridge / Presenter / Controller o dalla View. Invece, si utilizza uno schema di Osservatore, eventi o programmazione reattiva per consentire al bridge di iscriversi alle modifiche nel modello. E quindi puoi riformulare la tua responsabilità come:

"Allows outside subscribers (about which it knows nothing) to monitor it's state or calculation results."

Se il tuo Modello non ha dipendenze dal tuo Controller o Vista, è più facile da testare e molto più portatile.

    
risposta data 30.10.2014 - 20:56
fonte
5

Sospetto che una delle cose che ti sta confondendo è che ci sono due pattern completamente diversi che sono entrambi comunemente chiamati model-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 sedersi su il server con le viste sul client (forse come html renderizzato, o forse via ajax).

La tua descrizione mi sembra che si possa trovare nella maggior parte delle definizioni di web-mvc.

    
risposta data 30.10.2014 - 17:51
fonte
2

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

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

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

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

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

Modello

Responsabilità primaria: dati persistenti
Ruoli secondari: convalida gli aggiornamenti, notifica agli osservatori gli aggiornamenti

Visualizza

Responsabilità primaria: dati presenti
Ruoli secondari: accetta input, presenta UX

Ponte

Responsabilità primaria: dati di aggiornamento
Ruoli secondari: pulisci input, sincronizza dati e viste

    
risposta data 31.10.2014 - 04:14
fonte
0

Mentre il tuo schema suggerito sembra corretto in superficie e funzionerà senza dubbio per le piccole istanze, poiché la tua app diventa più complessa, dovrai affrontare problemi in cui non sei sicuro su cosa aggiorna cosa, chi ascolta dove e perché Sto tentando di controllare così tanti modelli da così tante viste, tutti coloro che hanno bisogno di accedere a loro, ecc.

Raccomando di estendere le tue idee usando il seguente schema (tratto dal discorso di Amy Palamountain Nemico dello Stato ):

Modelli

  • Stato sincronizzazione con l'archivio dati
  • Gestire la convalida dei dati nuovi / aggiornati
  • Aumenta gli eventi quando cambiano stato

Visualizzazioni

  • Modelli di rendering
  • Gestisci eventi del modello
  • Gestisci eventi DOM
  • Media l'interazione tra Modello e DOM

Controller

  • Gestisce al massimo un paio di Modelli e amp; Vista
  • Mantiene traccia delle viste all'interno di un contenitore

Moduli

  • Il raggruppamento logico di un controller e le sue viste e amp; I modelli
  • testabile
  • Piccolo e manutenibile (Single Responsibility)
  • Coordinate (tramite il Controller) lo stato e gli eventi delle Views & Modelli che contiene
  • Liberi di presentare le proprie viste
  • Non liberi di scegliere dove per presentare le sue viste

Gestore di layout

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

Dispatcher

  • Ascolta gli eventi (tramite stream PubSub globale)
  • Responsabile del caricamento di nuovi moduli in base agli eventi
  • Distribuisce i moduli caricati al gestore layout
  • Gestisce l'intera durata del modulo (creazione, pulizia, memorizzazione nella cache, ecc.)
  • Esempi di eventi:
    • Modifiche al percorso (incluso il percorso di caricamento iniziale)
    • Interazione utente
    • L'evento del modulo è ribollito da un evento del modello a causa della modifica dello stato sul lato server, ecc.

Applicazioni

  • Responsabile della configurazione generale, crea istantaneamente cose come:
    • Dispatcher
    • Router
    • stream PubSub
    • logger
    • etc

Questo tipo di pattern consente alla tua applicazione di essere componibile, unità testata, rimuove la complessità che un Bridge si accumula nel tempo, mantiene le preoccupazioni separate, ecc.

Come osserva Amy: fai attenzione a non costruire un server sul client. E fai attenzione a non cadere nella dottrina di "Sto facendo un framework MV *, quindi devo

risposta data 07.11.2014 - 00:32
fonte

Leggi altre domande sui tag