Mantenimento della coerenza con i livelli aziendali e di dati liberamente accoppiati

1

Segui la seguente sequenza di eventi:

  1. Il livello aziendale richiede i dati x e y dal livello dati.
  2. Il livello dati restituisce la versione 1 di x e y .
  3. Il livello aziendale inizia a eseguire la logica in base ai dati x e y .
  4. Un'altra operazione (concorrente) aggiorna i dati x alla versione 2.
  5. Il livello aziendale indica al livello dati di salvare nuovi dati z in base alla logica al passaggio 3.

I dati z salvati nel passaggio 5 ora sono stati salvati in base a dati incoerenti o "obsoleti". I dati x sono diventati obsoleti durante la transazione commerciale . Supponiamo ad esempio che data x contenga un flag che indica se è consentita la creazione di z di dati.

In passato ho visto questo problema affrontato da:

  1. Accoppia strettamente la logica aziendale con le operazioni sui dati. Ad esempio, la logica aziendale nelle procedure memorizzate RDBMS o la logica di co-mingling del codice dell'applicazione con operazioni di dati sensibili alla persistenza. o;
  2. Ignorare il problema perché la probabilità x impatto = troppo bassa per essere preoccupata con

La mia domanda: esiste una terza opzione valida? Qualcosa che assicuri coerenza mantenendo una sana separazione delle preoccupazioni tra il business e i livelli di dati.

Questo è qualcosa che gli ORM affrontano? So che si occuperanno di concorrenza ottimistica per i dati scrive , ma non voglio aggiornare i dati x , ma assicurati che nient'altro l'abbia aggiornato durante il corso della transazione commerciale. O più specificamente, che "la creazione di z è consentita?" il flag non è stato aggiornato.

Per qualsiasi risposta o commento specifico della piattaforma, sto lavorando con C # e Postgres.

    
posta Snixtor 15.07.2016 - 02:45
fonte

0 risposte

Leggi altre domande sui tag