tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" <>
Subject Re: Enterprise Java Beans (EJB)
Date Thu, 15 Aug 2002 17:11:15 GMT

Ned Wolpert wrote:
> Correct me if I'm wrong, but its still only the persistance side, right?
> Or would use use it to replace session beans?  I can see it replacing
> Entity beans, and the DAO layer uses entity beans; then your session
> beans would talk to the DAO layer which did all (only?) persistance.

Any bean that needs persistance should talk trough DAO. (and dao could 
be done using Enity beans, or rowset, etc.).
In your case, if you use session beans than right.

> So, it doesn't replace all of EJB, just EJB's entity beans, right?

However if you find EJB's slow and not scalable, than you would 
implement DAO another way. But since you would pull out Enity beans out, 
than there is not much reason to keep Session beans. You could just put 
regular form bean or java bean in session in some cases and get rid of 
EJB server and just use TomCat or Resin. (most app. servers have other 
ways to fail over). If you have reson to use session EJBs that use them, 
but I can think of no reason anyone would want to uses Enity EJB.

Back to original post.... Implement DAO interface to persisit (even when 
using EJB, so you can replace).


>>If you have an interface, such as DAO pattern, you could change the
>>implementation and not affect the rest of your application.
>>So ... make your persistance/CRUD and interface.
>>This lets you change how it does CRUD. You should be able to switch from
>> JDO to EJB or OJB to RowSet/ResulSet.
>>If you have to refactor the whole application to junk EJB or JDO... that
>> would not be great. A simple interface would do ya.
> Virtually,
> Ned Wolpert <>                     4e75
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message