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.