Mantenere il back-end dell'applicazione e l'interfaccia utente sincronizzati

1

Ho un'app che funziona con un elenco di oggetti, quindi ha un elenco con chiave centrale. La finestra principale ha un albero contenente questi oggetti con alcune informazioni, che è abbastanza facile da popolare come un evento singolo dopo il caricamento.

Ora, la parte complicata, qualsiasi parte dell'applicazione può aggiungere, rimuovere e, soprattutto, modificare i dettagli di tali oggetti in qualsiasi momento (tutti nello stesso processo) e vorrei che l'albero si aggiornasse per adattarsi.

Ho alcune opzioni tra cui passare gli eventi dall'oggetto alla lista fino al modulo che sembra essere il modo più flessibile. Posso anche farlo pigramente e ripopolare l'albero ogni volta o periodicamente (molto hacker).

Qualcuno ha qualche idea migliore su come strutturare questo?

Questo viene fatto in C # 2.0 ma i concetti si applicano a qualsiasi ambiente.

Grazie

    
posta Deanna 02.03.2011 - 12:59
fonte

2 risposte

2

Questa è solo un'applicazione e non una configurazione client del server corretta? In tal caso, utilizzerei un modello Observer con gli oggetti di base come oggetto e gli oggetti di visualizzazione come osservatori.

    
risposta data 02.03.2011 - 13:55
fonte
2

Ho risolto questo problema aggiungendo un Presenter . Essenzialmente, il presentatore è un intermediario. Tutte le interazioni tra l'interfaccia utente e il "back-end", come lo chiami, passano attraverso il presentatore.

Ora assumendo che quando affermi che "qualsiasi parte dell'applicazione può aggiungere, rimuovere e, soprattutto, modificare i dettagli di tali oggetti in qualsiasi momento", presumo cosa intendi per le parti in grado di avviare una sorta di modifica iniziano sempre dal livello dell'interfaccia utente (a meno che, naturalmente, non sia in esecuzione qualche tipo di attività asincrona in background ...)

Poiché tutte le azioni sono avviate dall'interfaccia utente, il relatore sa quando qualsiasi cosa accade che potrebbe cambiare lo stato. Il presentatore è responsabile della notifica delle parti rilevanti dell'interfaccia utente dopo che qualcosa accade che potrebbe influire sul suo stato. La soluzione ingenua, ma completamente realizzabile in molti casi, è quella di notificare sempre tutte le parti visualizzate dell'interfaccia utente dopo ogni azione avviata dall'interfaccia utente. (Questo è praticabile perché nella maggior parte dei casi l'interfaccia utente è una rappresentazione appiattita di una piccola parte del "back-end", quindi di solito non ci sono molte informazioni da sincronizzare - la quantità di dati è limitata dal reale schermo fisico- proprietà.) La notifica può essere qualsiasi meccanismo (nel mio, notifico solo l'oggetto dell'interfaccia utente superiore dell'albero e passa il messaggio a tutti gli oggetti dell'interfaccia utente figlio). Ogni oggetto dell'interfaccia utente è quindi responsabile di esaminare lo stato corrente, determinare se qualcosa è cambiato e quindi aggiornare ciò che sta visualizzando, se necessario.

Un'altra alternativa: un bus dei messaggi. È un po 'più pulito degli eventi (con gli eventi devi collegare e sganciare gli eventi da / a oggetti, e se dimentichi, ottieni l'equivalente di perdite di memoria). Con un bus dei messaggi, qualsiasi oggetto può inviare un messaggio: "qualcosa è cambiato!" e chiunque può iscriversi a quei messaggi. Ad esempio, controlla l'infrastruttura di messaggistica in MVVM Light. È bello in quanto utilizza i riferimenti software, quindi non ha il potenziale problema di perdita di memoria degli eventi.

    
risposta data 02.03.2011 - 15:35
fonte

Leggi altre domande sui tag