Da quello che ho letto, i progetti CQRS comprendono comandi asincroni in cui i comandi vengono messi in coda. L'utente presuppone che tutto sia a posto e che i sondaggi dell'interfaccia utente o un timer ottengano qualche feed back se tutto funziona o meno.I comandi devono essere asincroni in CQRS?
Come funzionerebbe se avessi un'interfaccia utente in cui trascino le cartelle in un albero? Potrei avere un utente che cancella una cartella mentre un altro lo trascina (per trasformarlo in una sottocartella).
Quindi dall'interfaccia utente ho potuto mostrare che il trascinamento è avvenuto e quindi da qualche controllo del timer per vedere se il mio modello letto è stato aggiornato (vale a dire controllare la cartella principale della cartella trascinata e se è impostata correttamente I sapere che ha funzionato).
Se l'utente ha eseguito un numero di operazioni di trascinamento, dovrei tenere un elenco di queste operazioni nell'interfaccia utente e controllare l'archivio di lettura (rimuovendo qualsiasi comando riuscito dall'elenco).
Forse ci sono modi migliori per farlo.
Sembra solo un sacco di lavoro sull'interfaccia utente e più incline all'errore mentre se eseguo solo un comando sincrono e se tutto va bene, passerò alla mia prossima operazione.
Grazie per la risposta. –
Lo vedo più come sforzo per informare gli utenti al più presto se le loro azioni hanno successo o meno. Dal mio punto di vista, quindi, è sbagliato da un punto di vista dell'usabilità dell'interfaccia utente per consentire agli utenti di trascinare allegramente le cartelle solo per "richiamare il server" alcuni secondi più tardi e scoprire che tutte queste azioni sono state rifiutate - penso che l'utente debba essere informato immediamente. Lo stesso caso per problemi con il salvataggio dei dati (si pensi alla convalida!), E la maggior parte se non tutte le altre condizioni di errore. – Dav
"Il tentativo di informare gli utenti al più presto se le loro azioni hanno successo o meno" non è un requisito universale che ogni sistema deve soddisfare. Se lo stato corrente dell'applicazione è fondamentale per determinare le azioni disponibili per l'utente, i comandi asincroni non sono probabilmente la decisione di progettazione migliore, ma ciò non significa che l'uso di comandi sincroni sia un punto magico che impedirà allo stato di cambiare * tra i comandi emessi da un singolo utente *. – arootbeer