Mingling transazioni DB e registrazione da una prospettiva di progettazione

Question

Mingling transazioni DB e registrazione da una prospettiva di progettazione

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

1

Supponiamo di avere una pagina di visualizzazione in cui gli utenti eseguono azioni in più passaggi, alcune di queste azioni comporterebbero operazioni DB con transazioni (i frammenti sono in pseudo-codice come from):

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Call ActionX

    Step 3:
        ...    

ActionX: # can be called from different points in the view
    ...
    Begin Transaction
    DB ops
    End Transaction

Diciamo che vogliamo registrare l'avanzamento dell'utente nella vista (o salvare alcuni stati) in modo persistente nel DB, in modo che se il programma / l'app viene interrotto possiamo ristabilire lo stato all'ultima azione dell'utente all'interno una vista:

View1:
    Step 1:
        ...
        Logger.log('view1-step1-done')

    Step 2:
        ...
        Call ActionX
        Logger.log('view1-step2-done')

    Step 3:
        ...
        Logger.log('view1-step3-done')

Ora, idealmente, vorremmo avere la registrazione persistente e le azioni transazionali basate su DB da fare entrambe nella stessa transazione DB, perché non vogliamo creare uno stato incoerente dove viene eseguita un'azione ma non si riflette nello stato del registro o viceversa.

La domanda è: come raggiungere il suddetto obiettivo con il minimo interdipendenza e SOC. Alcuni suggerimenti, ad esempio:

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Begin Transaction
        Call ActionX    # begin/end transaction statements will be removed from ActionX
        Logger.log('view1-step3-done')
        End Transaction

    Step 3:
        ...

Non piace perché la gestione delle transazioni appartiene naturalmente all'azione stessa.

Oppure, un altro:

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Call ActionX (logMsg='view1-step3-done') 

    Step 3:
        ...

ActionX (logMsg): 
    ...
    Begin Transaction
    DB ops
    Logger.log(logMsg)
    End Transaction

Non ti piace neanche questo. La gestione dei messaggi di registro non appartiene alle azioni.

design-patterns transaction

posta Basel Shishani 28.12.2012 - 05:30

fonte

2 risposte

1

Una transazione nidificata funzionerebbe se il tuo database li supporta.

View 1:
Step 1:
    ...

Step 2:
    ...
    Begin Transaction
    Call ActionX    # begin/end transaction statements will be removed from ActionX
    Logger.log('view1-step2-done')
    End Transaction

Step 3:
    ...

ActionX (): 
...
Begin Transaction
DB ops
End Transaction

risposta data 28.12.2012 - 14:58

fonte

Leggi altre domande sui tag design-patterns transaction

Sistema di token più semplice per l'autenticazione e l'autorizzazione OOD: tutte le classi nella parte inferiore della gerarchia contengono lo stesso campo

score 2 · Accepted Answer

La guida principale per questa domanda è di separare le responsabilità.

Sembra che tu stia cercando di collegare lo stato transazionale di un'azione con lo stato transazionale del log, e penso che sia un errore. Registra le modifiche all'azione in base all'azione. Registrare lo stato del registro in base allo stato risultante (restituito). Se l'azione ha esito positivo, quindi registra un messaggio di stato riuscito. Allo stesso modo, se l'azione non è riuscita, quindi registrare un messaggio di errore in tal senso.

Poiché i messaggi di log sembrano indicare lo stato dalle viste, quindi è responsabilità delle viste gestire la registrazione.

Se i messaggi di registro sono correlati agli aspetti interni dell'azione, l'azione dovrebbe assumersi la responsabilità della registrazione.

Tieni presente che queste due posizioni non sono l'una esclusa l'una dall'altra. Potresti scoprire che devi registrare sia i progressi della vista sia gli aspetti interni dell'azione. A quel punto, avresti entrambe le aree (Views e Action) che effettuano le chiamate di registrazione.