• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Facades, Entity Beans and DAOs

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Henrique Sousa
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
He loves you so much! And I'm baking the cake! I'm going to put this tiny ad in the cake:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic