I have a three-tier architecture that looks something like this:
Client → Business → Data
Where should transactions begin?
One school of thought says that transactions should only begin at the top of the data layer. The business layer only manages business objects with business logic and never knows about transactions. A business does all its work in manipulating objects, and then transfers them to the level of data that needs to be saved. This is a somewhat RESTful philosophy applied to lower levels.
Another school of thought says that transactions should begin at the top of the business layer. The Business level defines logical units of work, not the data level, because a logical unit of work sometimes contains business logic, not just data logic.
I like the idea of bringing transactional problems as close as possible. But I also believe that this may require additional design efforts and problems to try to keep the business logic from the data layer, unless it is just a CRUD operation. If you use RESTful design patterns with a sledgehammer, you can make your applications have very few operations other than CRUD.
There is even a third school of thought, which states that the client can run transactions so that he can combine several business operations when necessary. But now does the customer determine the unit of work? Isn't that a business problem?
A fourth school of thought says that my clients can simply be SOA components that can participate in an XA transaction that runs even outside the client.
Our developers would like some standards to be more specific than just “Start transactions, wherever you are.”
Does anyone have any opinions or suggestions on this?
Thank!
source
share