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.