Separazione della logica aziendale da DB-logic con le transazioni

Question

Separazione della logica aziendale da DB-logic con le transazioni

#1 da (5 voti)
#2 da (4 voti)

9

Abbiamotrelivellinellanostraapplicazione.Livellodiservizioperfornireun'APIesterna.LivelloBOperlanostralogicaaziendaleeunostratoDAOperlanostraconnessionealdatabase.

Diciamoognivoltacheaggiorniamounfile,vogliamoanchecambiarequalcosanellacartella,adesempio"ultima data di modifica". Questo deve essere fatto in una transazione. O ha successo e sia File sia Folder sono stati modificati. Oppure c'è un errore e la transazione viene ripristinata in modo che entrambi gli oggetti si trovino nello stato precedente.

L'azione "Modifica una cartella quando un file viene modificato" è pura logica aziendale. Quindi questo significherebbe che appartiene al livello BO. Tuttavia, utilizziamo Objectify per il nostro database, quindi per avviare una transazione dobbiamo chiamare ofy (). Transazione (...). Se chiamiamo questa funzione nel livello BO, questo interrompe il nostro progetto in quanto ci saranno chiamate specifiche del database (Objectify) nel nostro livello aziendale.

Quale sarebbe una soluzione pulita per questo problema?

design java design-patterns transaction

posta Serge Hendrickx 04.10.2016 - 10:17

fonte

2 risposte

Leggi altre domande sui tag design java design-patterns transaction

Gli script Perl non hanno davvero estensione? Il join di Python sembra non concentrarsi sugli elementi da unire, ma sul simbolo, rispetto a Ruby o Smalltalk, per un motivo di progettazione?

score 5 · Answer 1

Il modo in cui tagli le tue transazioni è in effetti una logica aziendale. Quindi, il tuo livello DAO fornisce un'API db framework indipendente per il metodo transact che hai menzionato (e probabilmente per cose come commit e rollback ). Quindi puoi usarlo dal tuo livello BO senza renderlo dipendente dal tuo database o dal tuo framework db.

score 4 · Answer 2

Sembra che Objectify sia progettato per transazioni di tipo atomico ( Transazioni di Google Application Engine ). Ti richiederà di sviluppare la tua astrazione di Gestione delle transazioni .

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

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

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

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

In breve, il modello si propone di incapsulare le regole aziendali in Transazioni commerciali (unità di lavoro). Il pattern consente l'ereditarietà tra B.Ts e fino ad ora vedo Objectify . Supporta anche la composizione. Quindi, per composizione o ereditarietà, l'approccio consente B.Ts .

complessi

Applicato all'architettura data, sarebbe simile a:

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