• 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

Why not EntityBean? (Cade's book)

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The case study in Cade's book does not use entity bean at all.
On page 172, the OrderProcessor StatelessSessionBean calls OrderDAO directly. I thought we could use an entity bean between the two so that OrderProcess->OrderEnityBean->OrderDAO->EIS. Is that because the persistent layer after the OrderDAO is a legacy system? Does it mean that we should avoid using entity bean when dealing with legacy systems? If not, in what situation we should use entity beans when dealing with legacy systens?
Thanks for your tips in advance.
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thats correct...since there is legacy system, so cade hasnt used entity bean for 'order'...
as u know it, we model on entity bean when the data mapping is not a prob...further from a design view, when the 'object' in question is in shared write mode entity beans r favored.
 
John Wen
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In what situation we should use entity beans when dealing with legacy systens?
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
I do think that EntityBeans can be used in the situation of the case study. If you look at the Customer Component Diagram you can see that the CustomerDAO does not use any subsystem to persist the account information.
Problem however is that the account information is aggregated from Customer, Address and CreditCard object(s). To solve this you can use the Composite Entity design pattern (see http://java.sun.com/blueprints/patterns/CompositeEntity.html). While I think that with EJB 2.0 this is a good solution (using CMP and CMR), with EJB 1.1 this solution involves quit a lot of coding.
I think that Mark Cade with EJB 1.1 in mind chose for the simplest (thus best) solution, but with EJB 2.0 EntityBeans are a viable solution.
Edward Peters
 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also think that not using EntityBeans is a design choice rather than what is at the backend. Implementing DAO pattern means datasource can be anything. No matter what the datasource, we could still use EntityBeans between the SessionBean and DAO layers. So we assume making DAO calls from SessionBeans is preferred for the Part II solution? Also, isn't BusinessDelegate preferred in between SessionBean and Servlet?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic