> 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 <[EMAIL PROTECTED]> 4e75 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
