Come mantenere l'atomicità con un modello di servizio simile

Question

Come mantenere l'atomicità con un modello di servizio simile

#1 da (1 voti)
#2 da (0 voti)

1

Immagina un percorso in un progetto web MVC che gestisca la modifica di un utente del tuo prodotto. Puoi fare cose come cambiare il loro nome, la loro email, il loro gruppo, i loro ruoli e così via. Questi dati vengono messi in un modulo e inviati al server.

Ora immagina di avere un servizio UserManager per gestire queste azioni. Come posso assicurarmi che la mia rotta sia atomica quando il processo potrebbe fallire dopo un numero arbitrario di azioni?

userManager.SetEmail(userID, newEmail) // passes, no duplicate emails, email ok.
userManager.SetPassword(userID, newPassword) // passes, password validates.
userManager.SetGroup(userID, newGroupID) // FAIL!!! group id is invalid or something.

Le funzioni sopra riportate altererebbero l'e-mail e la password prima di fallire nell'impostazione del gruppo.

Come si può evitare?

design-patterns mvc

posta Steve 20.04.2015 - 15:49

fonte

2 risposte

Leggi altre domande sui tag design-patterns mvc

Modelli di archiviazione dei dati per il salvataggio intermedio di un modulo del flusso di lavoro basato sul Web Dividi una grande classe nelle sottoclassi

score 1 · Answer 1

Devi utilizzare un ricordo .

Ad ogni passaggio si guarda lo stato precedente e lo si memorizza in un oggetto temporaneo. Se in qualsiasi momento si verifica un errore che richiede il rollback, è sufficiente guardare ciascun memento e ripristinare lo stato originale. Normalmente questo dovrebbe essere fatto come stack LIFO per garantire che le modifiche vengano annullate in ordine inverso.

Nota il termine "rollback" qui: ad un livello elevato, questo è esattamente il modo in cui le transazioni ACID funzionano in moderno database relazionali. È la stessa idea in un database come nel tuo esempio.

score 0 · Answer 2

Se "userManager" espone metodi separati per l'impostazione dell'e-mail, della password, ecc., espone esplicitamente un modello in cui è possibile prevedere un errore parziale.

Certo, puoi rollare il tuo meccanismo di rollback come suggerito da Snowman, ma penso che sarebbe più facile (più pragmatico forse?) aggiungere semplicemente la possibilità al tuo "userManager" di accettare un intero gruppo di proprietà da modificare a una volta, (atomicamente,) in modo che sia responsabilità di userManager assicurarsi che tutte le operazioni abbiano esito positivo prima di applicarle, o utilizzare qualsiasi meccanismo di transazione possa essere reso disponibile dagli rdbms sottostanti, la cui esistenza è cercando di astrarre.