Interazione tra modelli e dati auto-modificanti in Qt MV

0

Ho una struttura ad albero che rappresenta un sistema di dispositivi collegati al PC tramite porta seriale. In un certo senso, questa struttura è stata ispirata dall'esempio del modello ad albero in Qt e penso che questo aiuti a separare la parte logica dal gui. Il mio modello ha un membro nodo radice e può accedere a tutti i nodi sottostanti attraverso il nodo radice. Alcuni nodi dovrebbero fare il loro lavoro automaticamente (cioè inviare comandi alla porta seriale sul timer). Le attività di routine per l'applicazione sono ordinarie:

  1. Notifica il modello quando lo stato di un nodo è cambiato.
  2. Notifica il modello quando la struttura dell'albero è stata modificata, un nodo ha aggiunto un nuovo nodo figlio o ha rimosso un nodo.

Ogni nodo ha un puntatore alla radice e può emettere segnali su qualsiasi cambiamento. Quindi il nodo radice è una sorta di interfaccia per l'albero. Ora sono in difficoltà con l'arresto anomalo durante la rimozione di un nodo figlio e la notifica del modello. In realtà ho risolto questo problema, tuttavia penso che sia qualcosa di sbagliato nel design. Quindi voglio chiedere il modo migliore per implementare l'interazione tra la mia struttura dati e il modello.

Alcune domande sono: la struttura dei dati dovrebbe essere in grado di eseguire alcune azioni su se stessa (aggiungere o rimuovere nodi) e solo notificare il modello sulle modifiche, o che dovrebbe essere rigorosamente eseguita dal modello su richiesta appropriata dall'albero?

Uso Qt, segnali e slot, è sbagliato se la mia struttura si basasse sulla meccanica di QAbstractItemModel - utilizza segnali come nodeIsAboutToBeRemoved / nodeRemoved per preparare il modello per le azioni corrispondenti?

Aggiornamento, sulla struttura che sto usando. Non insisto che l'albero sia la migliore o la struttura ideale per i miei scopi. Ci sono due riflessioni sull'albero: rappresenta naturalmente il sistema reale ed è facile usare i modelli e le viste di Qt (sia in pianta che in tabella). Infine, l'idea dell'albero fu accettata dai capi e dai colleghi. Il mio albero ora è a 5 livelli: root - hub (rappresenta la porta seriale) - dispositivo coordinatore - dispositivo terminale - sensore. Successivamente, è possibile inserire un nuovo livello tra il dispositivo coordinatore e il terminale e una classe hub può essere reimplementata per l'utilizzo di qualcos'altro invece della porta seriale o per utilizzare un altro protocollo. Non c'è il multithreading adesso e non è pianificato, ma mi sembra che il multithreading possa essere iniettato relativamente semplice e naturale. Ogni hub controlla le impostazioni di poort seriale. Il nodo ad ogni livello conosce tutti i nodi figlio e quindi sa come formare una serie di comandi per il rilevamento dei dispositivi fisici. Ogni nodo può mantenere il suo stato (è accessibile a livello fisico o meno) e passare questo stato ai bambini o semplicemente controllare il loro comportamento.

    
posta qloq 14.07.2017 - 15:46
fonte

2 risposte

0

Che scopo ha questo server della struttura ad albero?

Perché non hai solo un elenco di dispositivi collegati?

Quindi, hai una classe hub di comunicazione. Ogni dispositivo ha un riferimento all'hub di comunicazione, che consente ai dispositivi di iscriversi agli eventi di loro scelta, nonché di attivarli.

Avere tutto ciò che parla a ciascuno in una sorta di albero suona eccessivamente complesso e inutile. Matematicamente, è molto meno efficiente. L'unico svantaggio di un modello di hub centrale è che, se si utilizza il multithreading, è possibile sprecare molti cicli sul codice di blocco nell'hub; tuttavia, anche il modello ad albero presenta questo problema, anche se in misura leggermente inferiore.

    
risposta data 14.07.2017 - 17:08
fonte
0

In MV di Qt ogni vista mostra un singolo modello.

In genere lo implemento rendendo un modello una composizione degli elementi della struttura dati. Quindi gli elementi della struttura dati ereditano QObject e inviano notifiche utilizzando il meccanismo segnale / slot. Questo ha l'ulteriore vantaggio che i segnali e gli slot di Qt sono a prova di thread se dovessi aver bisogno del multithreading. È possibile propagare le modifiche in alto e rendere il nodo root notificato al modello o passare il puntatore del modello su nodi diversi e notificarlo direttamente.

L'intera cosa cambia leggermente se si dispone di una sorta di vista di dettaglio - quindi potrebbe essere necessario un modello per ciascun elemento.

Tutto ciò suona come una sorta di dati non persistenti: non mi preoccuperei di separare i dati dall'implementazione del modello a meno che non si tratti di un progetto enorme.

Nel tuo progetto ogni livello dell'albero rappresenta un diverso tipo di oggetto in modo da poterli rappresentare con classi separate.

La modifica dei dati è possibile ma è necessario segnalarlo correttamente, altrimenti si verificano arresti anomali.

    
risposta data 12.03.2018 - 09:10
fonte

Leggi altre domande sui tag