Howdy, ranchers?
Let me start stating that I am
not an expert in OOP or
Patterns. I may say something obviously wrong for some of you, yet I'll need some explanation. Second of all, I'll use Sun's notation Transfer Object instead of Value Object for personal reasons, feel free to use whichever you like.
Well, I've been programming according to the usual design in the business tier: Session Facade as entry points for client calls and business processing, Entity Beans (BMP) for object representation, Data Access Objects for persistence and Transfer Objects being passed all around. As I double-checked the resulting software, I realized that all business methods were in the Facade, while all persistence was in the DAO.
What would stop me from taking the Entity Beans out of the game?
Then I would have client objects communicating with the Facade (no change happens as far as the client can see), which uses the DAO for persistence whenever required, using Transfer Objects for data representation.
I can see that concurrency could be an issue, but using Transfer Objects causes the same problem. Once you get the Transfer, you are no longer aware of the current entity state. Database access maybe? I don't know, but it doesn't sound bad.
Any thoughts? Thanks in advance