We have three layers in our application. Service layer to provide an external API. BO layer for our business logic, and a DAO layer for our database connection.
Let’s say every time we update a File, we also want to change something in the Folder, for example ‘last modified date’.
This needs to be done in a transaction. Either it succeeds and both File and Folder are edited. Or there’s a failure and the transaction gets rolled back so both objects are in the previous state.
The “Edit a folder when a file get edited”-action is purely business logic. So this would mean it belongs in the BO-layer.
However, we use Objectify for our Database, so to start a transaction we need to call ofy().transact(…).
If we call this function in the BO layer, this breaks our design as there will be Database specific calls (Objectify) in our Business layer.
What would be a clean solution for this problem?
4
How you cut your transactions is indeed business logic. So let your DAO layer provide a db framework independent API for the transact method you mentioned (and probably for things like commit and rollback). Then you can use it from your BO layer without making it dependent from your database or your db framework.
Looks like Objectify is designed for atomic-like transactions (Google Application Engine Transactions). It will demand to you to develop your own abstraction of the Transaction Management.
In this case. the abstraction goes on How do I delegate the transaction management to upper layers?
@DocBrown approach looks the faster and cleaner solution for the given architecture (layered). It also seems the safest given the little info we have about the context.
I suggest checking out UnitOfWork design pattern for the business layer because it suits with the transaction management purposed by Objectify.
Briefly summarised, the pattern aims to encapsulate business operations as a whole (unit of work or business transaction). It contextualizes the changes that our business does in the state of the data.
Applied to the given architecture, would look like:
FileService -> FileBO : new EditFileTransaction().execute()
|-> ofy().transact(...)
|--> FileDAO.actionA()
|--> FolderDAO.actionA()
|-> [ofy().commit(...)|ofy().rollback()]
The example above assumes that FileDAO.actionA() and FolderDAO.actionA() make changes in the database, hence the ofy().transaction() at the beginning of the business transaction. Not modifying operations, as for example validations, may take place before beginning the transaction so in case of inconsistencies the business transaction (UoW) can be aborted safely.
2