File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Facades, Entity Beans and DAOs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Facades, Entity Beans and DAOs" Watch "Facades, Entity Beans and DAOs" New topic
Author

Facades, Entity Beans and DAOs

Henrique Sousa
Ranch Hand

Joined: Apr 29, 2004
Posts: 92
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


Henrique Sousa<br />SCJP 1.4<br /> <br />All men die, not all men really live - Braveheart, 1995
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi Henrique,

I guess what you are proposing is done via JDO, Hibernate and all of those...

They don't have entity beans in there..its all POJOs..

Regards
Maulin
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I'm far from being a J2EE expert, but somehow "Transfer Objects being passed all around" doesn't sound exactly right...

You might also want to look out wether you have a http://martinfowler.com/bliki/AnemicDomainModel.html


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
Henrique Sousa
Ranch Hand

Joined: Apr 29, 2004
Posts: 92
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.
Pj Murray
Ranch Hand

Joined: Sep 24, 2004
Posts: 194
In addition to looking at Martin Fowler's material, I suggest you look at:



http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html



http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm


http://c2.com/cgi/wiki?DataTransferObject





PJ Murray
CodeFutures - Java Code Generation
http://www.codefutures.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Facades, Entity Beans and DAOs