No, no, no. A DAO is a design pattern that acts as a conduit for data from your persistent objects (entity beans) that improves system performance.
Mark ----- Original Message ----- From: "Francisco Hernandez" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 4:11 AM Subject: Re: Model Persistence Survey > thanks for the clearification of that, I thought had used a DAO to implement > the persistence so that itself was the persistence mechanism > ----- Original Message ----- > From: "Keith Chew" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, January 23, 2002 11:55 AM > Subject: RE: Model Persistence Survey > > > > Hi > > > > FYI, Data Access Objects (DAOs) is not a persistence mechansim, it's a > > design pattern used to encapsulate the mechanism. The mechanism itself > can > > be JDBC (in the example you have given), Castor JDO, Sun JDO, or any other > > O/R mapping tools' API. > > > > Keith > > > > -----Original Message----- > > From: Francisco Hernandez [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 24 January 2002 8:23 a.m. > > To: Struts Users Mailing List > > Subject: Re: Model Persistence Survey > > > > > > DAOs are another way to do it, but using a framework is much better imo > > > > > http://java.sun.com/blueprints/code/jps13/src/com/sun/j2ee/blueprints/catalo > > g/dao/CatalogDAOImpl.java.html > > > > > > ----- Original Message ----- > > From: "Christopher Barham" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Wednesday, January 23, 2002 1:51 AM > > Subject: Re: Model Persistence Survey > > > > > > > > > > Hi, > > > I really think that Java Data Objects has a big future... see JSR012: > > > http://www.jcp.org/aboutJava/communityprocess/first/jsr012/index.html > > > Currently we are evaluating Forte Transparent Persistence, which is a > > > physical incarnation of Java Data Objects - see > > > http://java.sun.com/products/jdbc/related.html and > > > http://access1.sun.com/jdo/ > > > The Forte stuff (Transparent Persistence) is detailed here: > > > http://www.sun.com/forte/ffj/resources/articles/jdo.html > > > > > > So far it is working very well - Although I have some qualms about byte > > > code enhancement as the mechanism to get the TP activity into your > > classes. > > > If nothing else, it gives you an 'unknown area' to worry about in your > > code > > > - For every simple code bug so far we have immediately assumed it is to > do > > > with the 'magic' of TP messing something up - however, in every case, > (so > > > far), it has been a simple non-TP coding error that was the root cause - > > it > > > just took longer to track down :-) > > > > > > For quick and easy database adhoc code, I have also taken to using > > TableGen > > > now and then to ease generation of the JDBC aware base classes - it > gives > > > connection pooling and so on.... It's fairly old, but works nicely with > a > > > minimum of fuss. The only slight problem was that with Oracle you need > to > > > explicitly close the Statement in the disconnect method of the generated > > > class DatabaseAccess - it took a bit of head scratching to work out > where > > > the dreaded "too many open cursors" error was coming from :-( > > > http://freespace.virgin.net/joe.carter/TableGen/ > > > > > > Regards > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > Struts > > > Newsgroup To: > > [EMAIL PROTECTED] > > > (@Basebeans.c cc: > > > om) <struts Subject: Re: Model > > Persistence Survey > > > > > > 22/01/02 > > > 23:55 > > > Please > > > respond to > > > "Struts Users > > > Mailing List" > > > > > > > > > > > > > > > > > > > > > Subject: Re: Model Persistence Survey > > > From: Vic Cekvenich <[EMAIL PROTECTED]> > > > === > > > Oh, yeah, Castor gets votes. > > > > > > Vic Cekvenich wrote: > > > > > > > I do not like surveys. But I would like to get a feel for "How are > > > > people implementing the model persistence". Sort of a popularity > > > > contest. Also if you did not like it, how would you do it next time. > > > > So if you would please respond. > > > > > > > > How do you implement model persistence to a SQL DB. > > > > > > > > EJB (even for non-midleware needed webapps) > > > > > > > > Expreso features > > > > > > > > JDBC ResultSet w/ own base class > > > > > > > > i Village /Tourge > > > > > > > > JDBC RowSet > > > > ( > > > > > > http://download-west.oracle.com/otndoc/oracle9i/901_doc/java.901/a90211/rows > > et.htm > > > ) > > > > > > > > > > > > Other? > > > > Is there another way? > > > > > > > > > > > > Right now I like RowSet, but what is popular out there? > > > > > > > > > > > > > > > > Currious, TIA > > > > Vic > > > > > > > > ps: maybe one day those "hooks" grow on Sturts, so Struts takes a > stance > > > > on a good aproach for model persistance > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
