Esiste uno scenario in cui è utile mantenere le proprietà mutabili memorizzate nella cache negli oggetti di dominio per scopi diversi da quelli informativi?

3

Di solito in un modello di dominio, avrai oggetti, e quegli oggetti avranno proprietà mutabili e proprietà che sono immutabili - per esempio, un id / nome dell'istanza sarà immutabile, mentre alcune altre proprietà (proprietà specifiche che dipende dalle relazioni con altri oggetti) può variare nel corso della vita di un oggetto

Quindi, nel consueto scenario in cui più client accedono allo stesso archivio dati, lo strumento ORM di solito modella le colonne come proprietà e relazioni come elenchi, nella comprensione reciproca che qualsiasi proprietà mutevole potrebbe essere obsoleta nel client, ovvero , rappresentano solo cache dei valori delle proprietà.

Tuttavia, in molte circostanze, si vuole eseguire un'operazione che potrebbe richiedere lo stato effettivo delle proprietà mutabili, altrimenti l'operazione potrebbe fallire o produrre un danneggiamento dei dati, quindi in quei casi si tenterà un blocco nella riga in domanda, e se la riga è già stata modificata, si annulla o si interrompe. In ogni caso, l'operazione viene eseguita dall'applicazione client.

Ad un certo punto devo fare una domanda (stranamente, la sua rivelazione è sorprendente!), quindi credo che la domanda sarebbe: c'è qualche scenario in cui è utile mantenere memorizzate le proprietà mutabili oggetti di dominio per scopi diversi da quelli informativi? Dopotutto, se ci sono relazioni che ci interessano, diciamo che vogliamo attraversare i vicini di qualche oggetto, vorremmo farlo con il loro reale (non memorizzato nella cache) stati, che comportano una transazione di database, o qualche altro mezzo per fare atomicamente il processo (forse la mappa si riduce?).

    
posta lurscher 24.02.2012 - 21:29
fonte

1 risposta

3

Idealmente, vuoi minimizzare la sincronizzazione dello stato delle entità per evitare l'accesso non necessario al DB, quindi nei casi in cui non devi preoccuparti troppo dei conflitti tra risorse, il blocco ottimistico funziona bene.

Ci sono tre fasi per il blocco ottimistico:

  • Inizia: registra un timestamp che segna l'inizio della transazione.
  • Modifica: legge e scrive i valori del database.
  • Convalida: controlla se altre transazioni hanno modificato i dati che questa transazione ha utilizzato (letto o scritto). Controlla sempre le transazioni completate dopo l'ora di inizio della transazione. Facoltativamente, controlla le transazioni che sono ancora attive al momento della convalida.
  • Conferma / rollback: se non c'è conflitto, rendere tutte le modifiche parte dello stato ufficiale del database. Se c'è un conflitto, risolvilo, tipicamente abortendo la transazione, anche se sono possibili altri schemi di risoluzione.
risposta data 24.02.2012 - 22:06
fonte

Leggi altre domande sui tag