• 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

Local Entity Beans vs. DAO for read-only operation

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general, if you have a read-only operation, such as login, search, etc. would you use a DAO class or would you use a local entity bean? Local entity bean is supposed to get rid of all the remote overhead, so is it just as good as a DAO for read-only? Then what is the pros and cons for each? Personally, I believe that a DAO will still have a better performance over entity bean, even local one, without container's overhead with mapping, etc. Is that right?
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, you're right.
In read-only operations, choose DAO as pattern.
See: http://java.sun.com/blueprints/patterns/FastLaneReader.html
It's important to understand that EJB is not the correct solution to all the systems. EJB is recommended in cases where:
- Transactions is very important ( in R.O. operations, use DAO )
- Good Security
- High Concurrency
- Good Resource management
Of course, you can get those stuffs writing a lot of code by your hands using CORBA or RMI, but EJB specification came up to help you to development quickly and make your solution portable.
In my point of view, expose entity bean as remote object is a dodgy design :-) Use Session Facade:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
And prefer to use local entity beans to avoid network overkill.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The only problem is, if you are using CMP and DAO changes to table structure will mean changing the CMP mapping and changing the DAO SQLs....
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hanson Yuan:
In general, if you have a read-only operation, such as login, search, etc. would you use a DAO class or would you use a local entity bean? Local entity bean is supposed to get rid of all the remote overhead, so is it just as good as a DAO for read-only? Then what is the pros and cons for each? Personally, I believe that a DAO will still have a better performance over entity bean, even local one, without container's overhead with mapping, etc. Is that right?


Hi Hanson,
it depends of what kind of read-only operations you want to perform. For the login you could consider using an entity bean representig the user profile, because the entity beans can be cached in memory by the container (if the container is using the commit option A) which brings an enormous performance gain if the same profile is read frequently. Searching and/or reporting is another story: normally you need only a portion of the data that is loaded by the entity bean and using the sql to obtain that data is usually more efficient.
Dragan
reply
    Bookmark Topic Watch Topic
  • New Topic