Good point. Knowledge of entity beans should be more wide spread than
knowledge of DAO type products (Cocobase, Toplink, etc al) at least
currently. Sun is producing a new API called JDO though, and that might
provide some standardization on the mapping side of the house.
Cheers
Jay Walters
-----Original Message-----
From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 2:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Entity beans vs DAO(Data Access Objects)
no, DAO is a (tiered) pattern.
BL ----> DAO -----> Any DB
So BL coders only have to know about using the DAO of their choice (a
home-brewn one, or a commercial one, like CocoBase
http://www.thoughtinc.com/ ). Then, the DB may change, the SQL or whatever
might change (it could be dinamically generated or a series of Stored
Procedures). This is very extended practice in COM+, but I prefer the Entity
Bean approach for all the non-technical issues. Whenever you enter a company
that uses a DAO, you have to learn to work with and around it, all
development done by the company has this DAO as a dependency, etc. For
highly customized things it 0.k. but in a true enterprise environment, it's
likely to be quickly dumped in favor of a third party option to avoid doing
maintenance. The third party option works, but leaves you with many of the
same problems still; I'd rather have a spec on Entity Beans better than
re-inventing it on every enterprise; but it's a free world (mostly), and I
think that under very special circumstances, a DAO is a good solution.
My 2c,
JP
> -----Original Message-----
> From: Raju Kolluru [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 3:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity beans vs DAO(Data Access Objects)
>
>
> Hi,
> Is DAO same as JDO (java database objects) or is it one more
> "data objects
> access" api by sun ?
>
> -Raju
>
> Anup Maliyackel wrote:
>
> > Hi all
> >
> > I recently heard from a friend of mine that sun is
> considering scrapping
> > the Entity beans concept and is trying to push Message
> driven beans and
> > Data Access Objects+Session Beans as alternatives. The
> reason they have put
> > forward is performance bottlenecks for large applications.
> Any comments?
> >
> > I have a few questions regarding Data Access Objects
> >
> > 1. My idea of DAOs are that they abstract away the database
> specific stuff
> > from Java code and provide a clean separation between Java
> and Sql. Is
> > there anything more to it?
> > 2. Is there any pooling mechansim for such objects? If we
> are going for
> > Session beans+DAO instead of Session Bean+Entity Beans
> ,won't the absence
> > of object pooling for DAOs affect the application performance?
> > 3.Are there any special considerations that need to be
> taken it account
> > for application server clustering in case we go in for DAOs?
> > 4. I would like to have some more info into the prons and
> cons of this
> > approach versus using Entity beans. Any white papers?
> >
> > Regards
> > Anup
> >
> >
> ==============================================================
> =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
> ______________________________________________________________
> ______________
> For your protection, this e-mail message has been scanned for Viruses.
> Visit us at http://www.neoris.com/
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
