tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ned Wolpert" <wolp...@codeheadsystems.com>
Subject Re: Enterprise Java Beans (EJB)
Date Thu, 15 Aug 2002 17:43:51 GMT
> 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.

Well, this isn't the best forum for this, but Entity beans have a purpose,
just the vendor's over-hype of having people use them everywhere. The
strongest reason to use EJB entity beans is the deployment configuration
that you can set, and change (in certain cases) with a running ejb cluster.
I can't speak for DAO in this way, but for TopLink and Castor, that is
not really possible. (Currently. I'm working on Castor :-) Not to mention,
container managed persistance takes much away from the developer, and gives
it to the admin; which can be bad, no doubt.

Eh, really it boils down to architecture.  Each architecture has a their
limitations. DAO sounds nice, but like EJB, its 'yet-another-layer';
abstraction to provide for flexibility. It may be good (again, I never
used it) but its still a layer.  If you don't need that flexibility, then
its a cost/liability.

Virtually,
Ned Wolpert <wolpert@codeheadsystems.com>                     4e75




--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message