Separare la logica aziendale dalla logica DB con le transazioni

Abbiamo tre livelli nella nostra applicazione. Livello di servizio per fornire un'API esterna. Livello BO per la nostra logica aziendale e un livello DAO per la nostra connessione al database.

Diciamo che ogni volta che aggiorniamo un file, vogliamo anche cambiare qualcosa nella cartella, ad esempio "data ultima modifica". Questo deve essere fatto in una transazione. O ha esito positivo e sia il file che la cartella vengono modificati. Oppure c'è un errore e la transazione viene ripristinata, quindi entrambi gli oggetti sono nello stato precedente.

L'azione "Modifica una cartella quando un file viene modificato" è una logica puramente aziendale. Quindi questo significherebbe che appartiene allo strato BO. Tuttavia, utilizziamo Objectify per il nostro database, quindi per iniziare una transazione dobbiamo chiamare ofy (). Transact (...). Se chiamiamo questa funzione nel livello BO, questo interrompe il nostro design in quanto vi saranno chiamate specifiche del database (Objectify) nel nostro livello aziendale.

Quale sarebbe una soluzione pulita per questo problema?

— Serge Hendrickx
fonte

Non riesci a FileBOchiamare a FolderBO.edit(newDate)causa del problema di transazione?

— Scoperto il

java non ha un equivalente di c # TransactionScope?

— Ewan,

In Java, l'ambito della transazione dipende dal framework utilizzato. In JEE potrebbe essere gestito dal server delle app ma di solito è definito e gestito in modo dichiarativo tramite Frameworks come Spring (tramite annotazioni, xml, ...)

— Laiv

Non preoccuparti di provare a rendere diversi "livelli" della tua applicazione funzionalmente indipendenti / ignoranti l'uno dall'altro. Abbraccia l'idea che il tuo codice sia costruito per l'architettura che supporta e invece concentrati sul rendere quel codice ben composto rispetto a se stesso.

— Formica P

Risposte:

Il modo in cui tagli le tue transazioni è davvero una logica aziendale. Quindi lascia che il tuo livello DAO fornisca un'API indipendente dal framework db per il transactmetodo che hai citato (e probabilmente per cose come commite rollback). Quindi puoi usarlo dal tuo livello BO senza renderlo dipendente dal tuo database o dal tuo db framework.

— Doc Brown
fonte

Sembra che Objectify sia progettato per transazioni di tipo atomico ( Transazioni di Google Application Engine ). Ti chiederà di sviluppare la tua astrazione della Transaction Management .

In questo caso. l'astrazione continua Come delegare la gestione delle transazioni ai livelli superiori?

L'approccio di @DocBrown mi sembra la soluzione più rapida e pulita da implementare nell'architettura data ( architettura a strati ).

A causa della mancanza di troppe informazioni sull'applicazione e sul suo contesto, la soluzione di Doc mi sembra anche la più sicura.

Tuttavia, suggerirei di dare un'occhiata al modello di progettazione UnitOfWork per il livello aziendale . Penso che si adatti alla gestione delle transazioni proposta da Objectify .

Riassumendo brevemente, il modello mira a incapsulare le regole aziendali in Transazioni commerciali (unità di lavoro). Il modello consente l'ereditarietà tra B.T e finora vedo, anche Objectify . Supporta anche la composizione. Quindi, sia per composizione che per eredità, l'approccio consente B. complesse .

Applicato all'architettura data, sarebbe simile a:

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]

— LAIV
fonte