This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
Henrique Sousa<br />SCJP 1.4<br /> <br />All men die, not all men really live - Braveheart, 1995
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 29, 2004
Thanks for replying, guys.
Martin Fowler's article is exactly what has driven my thoughts. The thing is that I had (mostly) no business logic in the Entity Beans, but all of it was in the Session Beans acting as facades for them. They also did not acces the database directly to provide more flexibility -- even for using mock objects simulating the database in unit tests. Database access is done through Data Access Objects, and I suppose this is where Hibernate and POJO persistence solutions would come in. This is also written in Hibernate's FAQ: "So how can we get the best of both worlds? Easy! Use a Session EJB to control transactional scope, security, threading and remoteablity. Use Hibernate for persistence". This is exactly what I have in mind, just replacing Hibernate with DAO. By the way, it seems that Hibernate replaces the DAO pattern. Is that so? Back to the transfer objects. I am using them because I need a way to represent my entities both in server and client applications, but I cannot expose business details to the client (which involve security and transaction issues). The most simplistic solution is to have POJO representing the data, and they are of great importance in two places: they can be used in GUIs such as JSF and Struts and passed to persistence mechanisms without risking misuse of business logic. Still trying to better understand Fowler's article though. Any ideas are always welcome. Thanks again.