• 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

Entity Bean Vs. DAO

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not able to understand fully why under certain criteria(s), one should decide to use entity beans over DAO's wrapper by session beans or
DAOs over Entity Beans.
I would welcome input from expert on using entity beans in a project.
I would be extremly thankful if someone can give me an example, referring to some live project / application where people have used entity beans/DAO and have benefitted.
What all requirements in an application demand using entity beans or DAOs??
Thanks in advance.
 
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally, I would never use entity beans. Particularaly as there are other simpler and better alternatives (Hibernate springs to mind). Why avoid entity beans?
- EJBQL is a limited subset of SQL, and lacks some commonly used functionality.
- they are more complex than POJOs.
- you are forced to use EJBs to access your entity beans, whether it is appropriate or not.
- they tend to perform worse than a POJO DAO framework.
- they are not a portable as the specs claim - most advanced functionality tends to be container specific.
- JDO offer all and more of their functionality anyway, so I think even Sun sees them as having a limited life time.
- they are a bad choice performance-wise in applications where the most common DB operation are reads.
- containers using them can try to reimplement very well understood RDBMS functionality in the application layer, and get no where close to the sort of performance you get in the DB.
I still am yet to see them deployed successfully in a production application.
 
kumar santosh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you..
 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are trade-offs either way. There are three options:
session beans with DAOs,
entity beans with DAOs and BMP (Bean Managed Persistence)
or entity beans using CMP (Container Manager Persistence).
With DAOs you have to know both how to use JDBC well (not as easy as it seems) and how to use SQL. It is true that it gives you more control, and some projects use it for that reason. However entity beans with CMP has advantages of not needing to write database access code. The EJB container can optimise the beans in ways that it cannot using DAOs. Effectively the container writes its own DAOs and can handles them with optimisations like read-only, caching, finder access and more. Also most container provide useful extensions to EJBQL. So it depends what you want to do in the end.
I think comparisons need solid benchmarks - anyone have a good list?
 
reply
    Bookmark Topic Watch Topic
  • New Topic