Dovresti avere una separazione "modello" - "vista". Non deve necessariamente essere un pattern MV * semi-formalizzato (ad esempio MVC, MVP, MVVM, ad nauseam) o framework, ma l'idea di avere una rappresentazione computazionale (il modello) di alcuni aspetti dell'applicazione che viene resa (producendo la vista) e viene notificato quando il cambio degli input ha avuto un grande successo.
Il tuo potenziale dilemma evapora una volta presa questa prospettiva. Il problema è causato dal fatto che il pulsante "invia ID all'elaborazione". Il pulsante non dovrebbe fare questo. Il pulsante dovrebbe solo notificare il modello che è stato premuto. Il modello dovrebbe, se decide che è appropriato, inviare gli ID all'elaborazione. Se il modello utilizza valori memorizzati o letture dai controlli dell'interfaccia utente non è la preoccupazione del pulsante.
Questo sposta il problema nel modello, ma la situazione è più chiara lì. Il modello contiene i valori "autorevoli". Quello che viene visualizzato è solo un rendering di quei valori. Il modello non ha bisogno di consultare l'interfaccia utente per quei valori. In effetti, in genere si desidera che il modello ignori completamente l'interfaccia utente. Ciò consente al modello di essere testato senza dover simulare l'interfaccia utente. Consente inoltre a diverse o più interfacce utente di utilizzare lo stesso modello. Se il modello non è consapevole dell'interfaccia utente, non può certamente andare a recuperare i valori dai controlli dell'interfaccia utente, quindi qualcosa deve dire al modello cosa sta succedendo.
Essenzialmente, hai una "lingua" di eventi UI e una "lingua" degli eventi del modello di applicazione e hai bisogno di un adattatore tra questi. Il modello di visualizzazione del modello MVVM (o qualcosa di analogo) serve ruolo dell'adattatore. Gli eventi del modello di applicazione devono essere elaborati dal modello di applicazione come transizioni di stato atomico. Gli eventi dell'interfaccia utente, d'altra parte, saranno in genere più raffinati di quello. Il modello di visualizzazione acquisisce il flusso di eventi dell'interfaccia utente e li "aggrega" in eventi del modello di applicazione. Elm Architecture è una versione particolarmente chiara di questo concetto.
Ad esempio, considera un modulo per l'assegnazione di giocatori ai team. Il modello di applicazione è un elenco di squadre e un elenco di giocatori in ciascuna di queste squadre. Il modello di applicazione ha anche un evento AddPlayerToTeam(player, team) (tra le altre cose). L'interfaccia utente per aggiungere un giocatore è composta da una casella di testo per il nome del giocatore e un menu a discesa per la squadra. Non ci sono eventi del modello applicativo per gestire un modulo "Aggiungi giocatore" parzialmente completato. Invece, viene introdotto un modello di visualizzazione che ha gestori di eventi per gli eventi dell'interfaccia utente e può rappresentare un modulo "Aggiungi giocatore" parzialmente completato. Quando il testo viene inserito nella casella di testo, il modello di vista viene notificato e si aggiorna automaticamente. Allo stesso modo, quando i team vengono selezionati nel menu a discesa. Un pulsante premere quindi notifica al modello di visualizzazione che l'utente ha completato il modulo. Il modello di visualizzazione può quindi notificare il modello di applicazione di un evento AddPlayerToTeam dopo aver convalidato il modulo in modo tale da garantire che ci sia un giocatore e un team validi per fornire a quell'evento. Il modello dell'applicazione gestirà una convalida più profonda, ad es. che un giocatore può essere su una sola squadra. I modelli di vista vengono creati mentre la vista viene (ri) resa mentre i modelli di vista fanno parte della Vista a livello di applicazione nella suddivisione Modello-Vista a livello di applicazione. In questo approccio, nessun componente deve leggere direttamente dai controlli dell'interfaccia utente (eccetto eventualmente se un gestore di eventi richiede la lettura del suo controllo proprio anziché avere i nuovi dettagli in un parametro per il gestore eventi). D'altra parte, il modello di vista (per non parlare del modello di applicazione) è più di una semplice "variabile speciale solo per salvare lo stato".