Questa è una caratteristica molto comune nel software, e sono sicuro che c'è un intero accordo scritto, ma non so davvero quale sia il termine tecnico, quindi eccomi qui:
Sto parlando di dare al tuo servizio o prodotto la possibilità di salvare lo stato di alcuni dati per poterli accedere in futuro e le modifiche al rollback. Ciò creerebbe una cronologia delle modifiche e una raccolta di stati o backup salvati (anche se non necessariamente utilizzati come backup, proprio come una funzione di azione "annulla").
Lo scenario avrebbe una funzionalità che interagisce con più oggetti e vogliamo salvare lo stato che hanno in quel momento specifico in modo da poter eseguire il rollback a quel punto in qualsiasi momento.
Punti da considerare:
-
gli oggetti sono di tipi diversi e possono essere correlati tra loro
-
non tutte le informazioni contenute in un oggetto sono necessariamente rilevanti quando si tratta di salvare il suo stato. Ad esempio, quando si salva lo stato di
Beachcose cometemperatureotimesono rilevanti malocationnon lo è (la spiaggia non va da nessuna parte). -
dovremmo decidere il livello di dettaglio dell'azione di salvataggio. Andando per piccoli cambiamenti creerebbe un grande sovraccarico. Ma andare per cambiamenti più grandi ridurrebbe il livello di dettaglio a cui il sistema si applicherebbe, naturalmente. Preferirei quest'ultimo però.
Come dovrei avvicinarmi a questo?
-
quale sarebbe il design appropriato per il sistema di salvataggio dello stato?
-
quale sarebbe il design appropriato per il sistema di ripristino dello stato?
-
quale sarebbe un adeguato sistema di persistenza? Vai con il tuo database come al solito? O forse serializzare i dati e salvarli come file binario? (Immagino che questa sia una cattiva idea)
Sull'ultimo punto: se dovessimo usare il database (il 99% è sicuro che sarebbe la soluzione giusta) utilizzeremmo le stesse tabelle o creare quelle dedicate per il sistema di restauro? Posso vedere pro e contro su entrambe le decisioni.