I have code with the following architecture:
- Business objects (Represents business object [BO])
- DataBasedModel classes (Maps to DB tables)
Layered Architecture
- DAO (reads /write BO to DB, converts BO to DBModels and vice versa)
- Each table has a DAO
- I plan to have a manager layer on top of DAO.Manager will call DAOS.Manager handles business logic.And transactions
Consider that I have 3 tables: A,B,C
- BOs: are A_BO ,B_BO ,C_BO
- Managers: A_M,B_M,C_M
- DAOs: A_DAO,B_DAO,C_DAO
All write operations of BO are handles by respective Manager (e.g. To write into A_BO, manager A is always called).
For some operations, I need to access multiple tables/BO.
For example to insert a record into A, I need to check something into table B. Write of A is handled by A managed.
Can manager A call B_DAO? or should it only call B_Manager? and not access B_DAO?
Some concerns:
If manager calls some other manager I cannot put an @Transaction Annotation on manager and I will need one more layers on top of the Manager then.
Advertisement
Answer
I don’t see the differences of your DAO layer and manager layer. They seem to have the same responsibility: manage entities.
On the other hand I miss something like a business layer. Inside a business logic you will have usecases which need access to more than one entity. For example to store a new bill you will have updates on billing data, customer accounts, maybe warehouse stock and lots of other entities. All these updates should occur inside one transaction. Therefore you should see all functionylity defined in your current DAO and manager layer as one persistence layer, that’s functionality can only be used inside of transactions. To have one DAO per entity is a common pattern here.
Transactions should be triggered by some business layer where the supplied functionality does something usefull in terms of your application logic. That’s also the point where transaction demarcation and other aspects like permission checking can be implemented.